Mysql Zahlenlänge?

[Simon]

Moin

ich verstehe nicht ganz die Angabe der Länge bei Feldern vom zb. Typ TINYINT. Laut Mysqldoku können Zahlen von 0-255 bzw. -128-127, was bringt dann die Länge? Wenn ich also TINYINT (1) nehme, dann kann ich Zahlen von 0-9 eingeben? Wozu gibt es dann mehrere INT Typen? (TINYINT, MEDIUMINT, etc.)
Wenn man eh bei jedem die Länge dazuschreiben muss/kann?

Grüß euch, Simon

[Philipp Hasenfratz]

Halihallo Simon

ich verstehe nicht ganz die Angabe der Länge bei Feldern vom zb. Typ TINYINT. Laut Mysqldoku können Zahlen von 0-255 bzw. -128-127, was bringt dann die Länge?

Nun, eigentlich nicht viel, zumindest nicht bei INTEGER-Werten.
Über ZEROFILL kann man MySQL anweisen, die Zahlen mit fixer
Zeichenlänge auszugeben, was dazu führt, dass bei kleinen Zahlen
vorne alles mit 0 aufgefüllt wird, bis die angegebene Länge erreicht
wurde.

Bei DECIMAL-Typen ist die Angabe nötig, da diese intern als CHAR
gespeichert werden und somit die Angabe der Zeichen zwingend
erforderlich ist.

Bei FLOAT-Typen bringt die Angabe IMHO nicht viel...

Bei STRING-Typen ist sie natürlich deshalb zentral, um die maximale
Grösse des Strings festzulegen. Bei VARCHAR ist die Angabe wiederum
eher nebensächlich (obwohl bei Indexes wiederum wichtig ist, denn
dort muss VARCHAR wiederum als "CHAR" gespeichert sein). Bei CHAR
ist es natürlich sehr wichtig, da MySQL genau wissen muss, vieviel
Daten dafür reserviert werden müssen.

Wenn ich also TINYINT (1) nehme, dann kann ich Zahlen von 0-9 eingeben? Wozu gibt es dann mehrere INT Typen? (TINYINT, MEDIUMINT, etc.)

Jeder INT-Typ braucht unterschiedlich viel Speicherplatz. Wer weniger
Werte aufnehmen kann, braucht weniger Speicher. Es liegt also im
Interesse des Datenbank-Designers, den richtigen, passenden Typ zu
setzen. Es sollen alle Werte gespeichert werden, dennoch soll nicht
zu viel Speicher verschwendet werden.

http://dev.mysql.com/doc/mysql/en/Numberic_type_overview.html
http://dev.mysql.com/doc/mysql/en/Storage_requirements.html
http://dev.mysql.com/doc/mysql/en/Choosing_types.html

Wenn man eh bei jedem die Länge dazuschreiben muss/kann?

depends, siehe oben.

Viele Grüsse

Philipp

[Simon]

Ok, welcher Datentyp wieviel Speicher braucht weiß ich jetzt, welche Zahlen wo reinpassen wusste ich schon. Ist das jetzt so zu verstehen, dass wenn ich ein MEDIUMINT mit einer Länge von 3 anlege, trotzdem der gleiche Speicherplatz verbraucht wird, als wenn es die volle Länge hätte? Voll sinnlos irgendwie.

[Philipp Hasenfratz]

Halihallo Simon

Ok, welcher Datentyp wieviel Speicher braucht weiß ich jetzt, welche Zahlen wo reinpassen wusste ich schon. Ist das jetzt so zu verstehen, dass wenn ich ein MEDIUMINT mit einer Länge von 3 anlege, trotzdem der gleiche Speicherplatz verbraucht wird, als wenn es die volle Länge hätte? Voll sinnlos irgendwie.

Genau ;-)

Wobei "sinnlos" etwas übertrieben ist :-)

Viele Grüsse

Philipp

[Simon]

Danke.

Wobei "sinnlos" etwas übertrieben ist :-)

Naja, Sinnvolles kann ich daran nicht entdecken. Da wäre es einfacher gewesen nur den Typ INT zu haben und eben je nach maximaler Länge auch die größe zu verbrauchen.

[Philipp Hasenfratz]

Halihallo Simon

Wobei "sinnlos" etwas übertrieben ist :-)
Naja, Sinnvolles kann ich daran nicht entdecken. Da wäre es einfacher gewesen nur den Typ INT zu haben und eben je nach maximaler Länge auch die größe zu verbrauchen.

Falsch, umgekehrt. Es ist sinnvoller den Typ zu setzen und ggf. die
Längenangabe wegzulassen. Falls Du "INT(3)" definieren würdest,
müsste ein SMALLINT angelegt werden, nur, weil die Nummer 999 auch
noch in den Zahlenbereich mit drei Stellen einordbar wäre, obwohl
vielleicht nur Zahlen bis 255 gespeichert werden müssten und somit
ein TINYINT ausreichen würde.
Falls du schon nur einen INTEGER-Typ wünschst und die Länge angeben
möchtest, so wäre einzig und alleine eine Byte- oder Bit-Angabe
sinnvoll => der Speicherverbrauch also, denn nur das ist für MySQL
relevant.

Viele Grüsse

Philipp

[Philipp Hasenfratz]

Halihallo

Falsch, umgekehrt. Es ist sinnvoller den Typ zu setzen und ggf. die
Längenangabe wegzulassen. Falls Du "INT(3)" definieren würdest,

Damit meine ich ein hypothetisches RDBMS deines Wunsches, nicht
MySQL, denn dort sind Typen bekanntermassen zwingend erforderlich.

Also du sagst deinem RDBMS "INT(3)", also ein Integer mit drei
Stellen. Wie soll dein RDBMS denn nun dieses Konstrukt speichern?
Wieviel Speicherplatz braucht man für eine Nummer mit drei Ziffern?
Hm. Maximal 1000 verschiedene Zahlen, also mindestens 10 bits. Puh?
Bits lassen sich nicht speichern, nur Bytes, also aufrunden und
teuren Speicherplatz verschwenden... Also, mindestens zwei Bytes,
folglich eines mehr, als bei einem TINYINT. Wenn du also weisst, dass
nur Zahlen bis 255 gespeichert werden müssen, ist die Angabe von
INT(3) in deinem RDBMS overkill, in MySQL geht dir kein Byte
*verloren* ;-)

Viele Grüsse

Philipp

[Simon]

Jetzt hab ichs gecheckt. Ich dachte nur an die sichtbare Länge, aber nicht an den echten Speicherplatzverbrauch.