MySQL PHPMyAdmin smallint(3)

[tobi.wld]

Hallo zusammen,

ich arbeite gerade an einem Projekt wofür ich eine Datenbank benötige.
In meiner Tabelle habe ich ein Feld (weatherID) welches 3 Stellen haben soll und als smallint abgespeichert werden soll.
Da ein smallint aber ja bis zu 32.767 bzw 65.535 abspeichert würde ich es gerne auf 3 Stellen begrenzen.
Wenn ich allerdings einen Insert mit beispielsweise 1000 mache speichert er Ihn so ab, obwohl ich die Grenze auf 3 Stellen begrenzt habe.

Jemand eine Idee wie ich das lösen kann?

 

[netzgestaltung]

vor dem speichern bearbeiten. soll gerundet oder abgeschnitten werden, entsprechend kannst die Werte vorher manipulieren.

 

[tobi.wld]

Ich möchte dass der Wert 1000 nicht eingegeben werden kann, dieser sollte zu 999 werden, anstatt 4 stellig zu bleiben.
Also alles was größer als 3 Stellen ist sollte auf 999 gesetzt werden.

Das Problem im Moment ist eher dass die Funktion zum setzen der Länge nicht funktioniert und er das einfach ignoriert.

 

[0x8100]

man könnte einen trigger verwenden, der die id vor dem insert auf werte >999 überprüft und bei überschreiten auf 999 setzt.

 

[RalphS]

Das Googlewort heißt constraint, an dieser Stelle check().

ALTER TABLE x ADD spalte SMALLINT CHECK(spalte < 1000);

 

[abcddcba]

Evtl. auch mal in der Dokumentation nachlesen was die Zahl 3 bei
smallint(3) in MySQL bedeutet:

For integer data types, M indicates the maximum display width. The maximum display width is 255. Display width is unrelated to the range of values a type can store, as described in Section 11.1.6, “Numeric Type Attributes”.

SMALLINT[(M)] [UNSIGNED] [ZEROFILL]

 

[DubZ]

bzw. vor der Datenbank (dem Topic entnehme ich, dass es wahrscheinlich ist, dass mit PHP gearbeitet wird) im Backup das Eingabefeld entsprechend überprüfen, bevor es überhaupt zum DB Query kommt.
Ansonsten wenn phpmyadmin tatsächlich die Eingabemaske sein soll und es kein Backend gibt, so wie bspw. RalphS gesagt hat

 

[RalphS]

Protip aus dem Datenbank-Anwendungsdesign:

Wenn es Einschränkungen geben soll auf den DATEN, dann den Check in die Datenbank. Manchmal reicht der Datentyp schon aus. Aber nicht immer.

Beispiel, ich habe eine strukturierte Spalte Inventarnummer.
Die hat das Format TYP-STANDORT-LFDNR, also zB MON-B-001 für "erster inventarisierter Monitor in Berlin".
Das ist eine Anforderung an das DATUM, nicht an die Anwendung. Also kommt ein Check in die Datenbank, der guckt, ob das, was eingetragen werden soll, zumindest wie Inventarnummer aussieht. Anderenfalls würde die Spalte inkonsistent werden können und das will man normalerweise vermeiden.

Punktuell gibt es aber natürlich auch anwendungs spezifische Checks. Ich habe einen Warenkorb und der soll nur heute gültig sein, da kann ich diesen Check in der Anwendung halten und muß das nicht in die Datenbank packen.

ALLE Nutzereingaben müssen in der Anwendung geprüft werden, und ja, insbesondere auch dann, wenn man dann mehrfach prüft.
Das EINE tu ich für die Integrität der Anwendung.
Das ANDERE für die Integrität der Daten.

Das sind zwei paar Schuhe. Jede Datenbank unterstützt so viele Anwendungen wie ich dafür bauen will... aber die Inventarnummer im Beispiel ist immer dieselbe Inventarnummer mit denselben Anforderungen an diese.