QUOTE (Jürgen Auer @ Mi 16.06.2010, 13:32)[...]
(1) Das Feld als nvarchar(6) definieren und beim Insert / Update die Nullen von links her auffüllen.
[...]
Ja, ein Nummernformat gehört
eigentlich ins Frontend, doch in diesen besonderen Fall, würde ich sagen, ist es hier noch etwas anderes, als wenn ich einen Geldbetrag speicher, denn hier geht es um eine fortlaufende eindeutige Nummer. Auch speicher ich eine einfache Zahl nicht als String in eine DB. Das ist für mich ein Spagat. Wir können ja drüber diskutieren, ob und welches Format nun in der DB steht, irgendeins wird es auch bei Floats oder Dezimalzahlen in der Datenbank gespeichert, und ist damit auch ein vorgebendes Format was man hier ändert.
QUOTE [...]
nvarchar [ ( n | max ) ]
Unicode-Zeichendaten variabler Länge. n kann ein Wert zwischen 1 und 4.000 sein. max gibt an, dass die maximale Speichergröße 2^31-1 Bytes beträgt. Die Speichergröße in Bytes ist doppelt so groß wie die Anzahl eingegebener Zeichen + 2 Bytes. Die eingegebenen Daten können 0 Zeichen lang sein. Die ISO-Synonyme für nvarchar sind national char varying und national character varying.
[...]
http://technet.microsoft.com/de-de/library/ms186939.aspx
Dann lieber ein entsprechender Datentyp in der Datenbank, insbesondere da dieser bei 4 Byte bleibt. Und ist immer noch besser als eine Speichergröße von 2 Byte pro Zeichen + 2 Byte, womit man im 1 stelligen Bereich bei je 4 Byte sind, und im Zweistelligen schon bei 6 Byte (3 Zeichen - 8 Byte bis 6 Zeichen - 14 Byte), was definitiv unsinniger ist als ein Integer zu nehmen, der eine Stufe höher ist, und halt immer noch 4 Byte lang ist pro Datensatz, und nicht pro weiterer Stelle um 2 Byte anwächst.
Aber auch hier ist immer noch gegeben, die Nummer entsprechend zu formatieren, aber wenn es sich hier um eine UID handelt (in diesen Falle eine Rechnungsnummer), finde ich es auch nicht unbedingt abwegig diese mit führenden Nullen in die DB zu schreiben, damit hier die Zuordnung leichter ist.
Für andere Dinge, wie Du sie oben beschreibst kann immer noch
number_format verwendet werden. Damit hast Du aber keine führende Nullen in Deinen Beträgen, macht hier aber auch kein Sinn, ist bei Deinen Beispiel mit den Preisbeträgen aber auch irgendwie nicht der Fall, würde auch nicht unbedingt funktionieren. So funktioniert das Auffüllen der Nullen bei MySQL nur bei einer vorzeichenlosen Ganzzahl, ergo unsigned zerofill
Für mich bleibt Dein Konstrukt von oben ein Spagat, da Du hier mit der Datenbank falsch umgehst. Da änderst Du absolut nichts mit schönreden dran.
Und damit wir gerade so schön dabei nochmal die Gebetsmühle: Man speichert Daten immer ins entsprechende Datenbankformat und nicht aus Bequemlichkeit in ein anderes Format, um dadurch ein Overhead an Speicherplatz zu verschwenden (Ja, ich hab da auch ein Fehler gemacht, das liegt aber an mangelnden Einsatz und des menschlichen Gehirn Dinge zu verdrängen).
Zu dem int(6), das heißt, nutze ein 4 Byte Ganzzahlen fällt mit der Maximallänge von 6 Zeichen, da kein Vorzeichen benötigt wird, wird 6 Zeichen verwenden. Ein Bigint wäre also überflüssig, ein smallint nicht ausreichen, da es nur 5 Zeichen ohne Vorzeichen hat. Mir fällt aber gerade auf, dass ein mediumint(3) auch reicht, dann wären wir bei 3 Bytes. Das unsigned im Befehlt sagt auch gleichzeitig, dass kein Vorzeichen benötigt wird, womit das erste Bit frei wird und der Werte Bereich sich verschiebt. Bei einen smallint auf 0-255 statt -128 bis 127 (mit 7 Bit lassen sich 128 Zahlen darstellen, mit 8 Bit 256 Zahlen, da wir mit der 0 beginnen halt von 0 bis 255).
http://dev.mysql.com/doc/refman/5.1/de/numeric-types.html
Und MySQL ist nicht 100% ANSI-konform, aber das soll afaik MS SQL auch nicht sein.
http://troels.arvin.dk/db/rdbms/
@Ronald:
Ein mediumint(6) reicht auch, sind dann nur 3 Byte Speicherbedarf und macht das macht schon etwas aus, selbst wenn es max. 1 Million Rechnungen sein können, den Typ hatte ich nicht mehr direkt im Kopf, hab länger nicht mehr intensiv mit MySQL gearbeitet.
1.000.000 Byte = 976,56 KB
