MySql - Spalte int(3) oder tinyint(3) unterschiede?

[hugole]

Mittag Selfer,

ich Frage mich gerade, was der Unterschied ist, wenn ich über phpmyadmin eine Spalte als tinyint(3) oder int(3) anlege. Beide ermöglichen doch das Speichern eines 3stelligen integers?

Grüßle

[suit]

ich Frage mich gerade, was der Unterschied ist, wenn ich über phpmyadmin eine Spalte als tinyint(3) oder int(3) anlege. Beide ermöglichen doch das Speichern eines 3stelligen integers?

jein, siehe hier http://dev.mysql.com/doc/refman/5.0/en/numeric-types.html

du kannst in TINYINT immer (unsigned) werte von  0 bis 65535 (2^16 bit) speichern und in INT immer 2^64 bit speichern - du beschränkst lediglich die anzeige auf 3 stellen im dezimalsystem

[Sven Rautenberg]

Moin!

ich Frage mich gerade, was der Unterschied ist, wenn ich über phpmyadmin eine Spalte als tinyint(3) oder int(3) anlege. Beide ermöglichen doch das Speichern eines 3stelligen integers?

jein, siehe hier http://dev.mysql.com/doc/refman/5.0/en/numeric-types.html

du kannst in TINYINT immer (unsigned) werte von  0 bis 65535 (2^16 bit) speichern

Nein, TINYINT ist 8 Bit!

und in INT immer 2^64 bit speichern

Und INT ist 32 Bit.

• du beschränkst lediglich die anzeige auf 3 stellen im dezimalsystem

Auch nicht korrekt formuliert: Diese "Breitenangabe" füllt Zahlen, die weniger Stellen haben, ggf. mit Nullen auf (bei ZEROFILL), ansonsten mit Spaces.

Steht alles auf der von dir verlinkten Seite - hättest du vielleicht vorher lesen sollen... :)

- Sven Rautenberg

[hugole]

Hallo,

Danke für die Antwort. Diese Übersichtseite habe ich nicht gefunde, da kann ich auch gleich mal die anderen Typen nachschauen.

Wie ist es eigentlich mit unsigned, kann ich das in phpmyadmin nicht bestimmen?

Gruß

[suit]

Wie ist es eigentlich mit unsigned, kann ich das in phpmyadmin nicht bestimmen?

doch sicher

in der attribute-spalte

[hugole]

Ah, danke!

Noch etwas, ich schaue mir gerade auch die anderen Typen an und bin bei Text gelandet.

Tinytext, Text, Mediumtext, Longtext mit
2^8, 2^16, 2^24, 2^32 +
1, 2, 3, 4 byte(s)

Nun ist meine Frage, ich kann mir hierunter nichts vorstellen.
Bisweilen hatte ich immer Text verwendet, aber das war natürlich nie voll. Wieviel text passt denn so grob gesprochen in Tinytext?

Grtuß

[Sven Rautenberg]

Moin!

Noch etwas, ich schaue mir gerade auch die anderen Typen an und bin bei Text gelandet.

Tinytext, Text, Mediumtext, Longtext mit
2^8, 2^16, 2^24, 2^32 +
1, 2, 3, 4 byte(s)

Nun ist meine Frage, ich kann mir hierunter nichts vorstellen.
Bisweilen hatte ich immer Text verwendet, aber das war natürlich nie voll. Wieviel text passt denn so grob gesprochen in Tinytext?

Steht doch da: 2^8 Bytes.

Wieviel ist 2 hoch 8?

Und dann ist noch zu berücksichtigen, welches Encoding für die Spalte gewählt wurde. UTF-8 verbraucht PRO ZEICHEN variabel viele Bytes, jedenfalls im Durchschnitt MEHR ALS EIN BYTE.

Andererseits bieten TEXT-Felder Einschränkungen bzw. Sonderbehandlungsnotwendigkeit hinsichtlich Indices. VARCHAR sollte für absehbar kurze Zeichenketten immer der Feldtyp der Wahl sein.

- Sven Rautenberg

[hugole]

Hallo,

absehbar kurz sind sie nicht.

Also kann ich für 2^8 bei UTF-8 mit 2 Byte pro Zeichen gerechnet 2^7 annehmen. Also 128, nuja das langt wohl nicht für einen Artikel oder ähnliches. Muss es wohl text bleiben.

Gruß

[suit]

Also kann ich für 2^8 bei UTF-8 mit 2 Byte pro Zeichen gerechnet 2^7 annehmen. Also 128, nuja das langt wohl nicht für einen Artikel oder ähnliches. Muss es wohl text bleiben.

wenn du 1 million datensätze hast und du entscheidest dich für zb überschriften, wo normalerweise nur kurze texte reinkommen, für ein überdimensioniertes feld, erzeugst du sehr viel overhead -

tinytext benötigt pauschal 1 byte, text schon 2, mediumtext 3 und longtext 4

du solltest einfach mal prüfen, welches der felder ausreicht - vielleicht ist text für einen artikel zu kurz und es ist mediumtext notwenig? - für einen artikel ist tinytext aber auf jeden fall zu kurz

beim obrigen beispiel erzeugst du etwa 1 mb overhead bei tinytext und 4 mb bei longtext

wenn du das pro feld rechnest, dass du falsch dimensioniert hast und dann noch ein system mit hunderten von tabellen hast, bekommst du leicht mal ein paarhunder mb overhead mehr zusammen, als du eigentlich willst ;)

[Vinzenz Mai]

Hallo,

wenn du 1 million datensätze hast und du entscheidest dich für zb überschriften, wo normalerweise nur kurze texte reinkommen, für ein überdimensioniertes feld, erzeugst du sehr viel overhead -

der Overhead ist vernachlässigbar, das ist Mikrooptimierung.
Sinnvoll für Überschriften wäre sicherliche VARCHAR statt irgendeinem der Text-Datentypen. Die Begründung dafür hat Sven schon geliefert.

Freundliche Grüße

Vinzenz

[suit]

der Overhead ist vernachlässigbar, das ist Mikrooptimierung.

wenn der overhead vernachlässigbar ist, wieso definiert man nicht gleich alles als longtext - damit hat man immer die option mehr reinzustopfen, ohne etwas umstellen zu müssen ;)

Sinnvoll für Überschriften wäre sicherliche VARCHAR statt irgendeinem der Text-Datentypen. Die Begründung dafür hat Sven schon geliefert.

wobei sich mir nicht ganz erschließt, warum es neben varchar auch noch tinytext und text gibt - varchar erfüllt quasi die selben anforderungen und braucht genau gleich viel speicherplatz - hat aber zusätzlich das feature, variabel groß zu sein - quasi bis zu einer länge von 255 zeichen verhält es sich wie tinytext und darüber wie text

oder sehe ich das jetzt falsch?

[suit]

Bisweilen hatte ich immer Text verwendet, aber das war natürlich nie voll. Wieviel text passt denn so grob gesprochen in Tinytext?

ein zeichen (ansi) benötigt in der regel 1 byte - unicode zeichen, zb als utf hinterlegt benötigen zusätzlich (je nach zeichen nochmal 2 bis 3 bytes)

der platzbedarf ist je nach datentyp auch noch mit etwas overhead (1, 2, 3 oder 4 bytes) verbunden

http://dev.mysql.com/doc/refman/5.0/en/storage-requirements.html

nehmen wir also den besten fall an, 1 byte pro zeichen

TINYTEXT = L + 1 bytes, where L <  2^8
2^8-1 = 255 zeichen passen maximal rein (weil ja L kleiner sein muss als 2^8, darum das -1)

LONGTEXT = L + 4 bytes, where L <  2^32 also 2^32-1 (=4.294.967.295), somit bringst du in longtext 4 milliarden zeichen unter

es kommt also drauf an in welcher zeichencodierung du texte hinterlegst und welche zeichen du verwendest

wenn du utf-8-inhalte speicherst und permament zeichen verwendest, die aus 4 bytes gebildet werden, kannst du in tinytext nur 63 zeichen reinpacken, wenn du nur ansi-zeichen verwendest - sagen wir "abcabc" bekommst du die vollen 255 zeichen rein

[Sven Rautenberg]

Moin!

wenn du utf-8-inhalte speicherst und permament zeichen verwendest, die aus 4 bytes gebildet werden, kannst du in tinytext nur 63 zeichen reinpacken, wenn du nur ansi-zeichen verwendest - sagen wir "abcabc" bekommst du die vollen 255 zeichen rein

Da MySQL nur die BMP von Unicode verarbeiten kann, treten nur UTF-8-Zeichen von maximal 3 Bytes Länge auf.

- Sven Rautenberg

[suit]

Nein, TINYINT ist 8 Bit!
Und INT ist 32 Bit.

hoppla - da bin ich wohl etwas verruscht ;)

Steht alles auf der von dir verlinkten Seite - hättest du vielleicht vorher lesen sollen... :)

jo, das kommt davon wenn man aus dem gedächtnis schreibt und nur noch verlinkt

[globe]

n'abend,

ich Frage mich gerade, was der Unterschied ist, wenn ich über phpmyadmin eine Spalte als tinyint(3) oder int(3) anlege. Beide ermöglichen doch das Speichern eines 3stelligen integers?

jein, siehe hier http://dev.mysql.com/doc/refman/5.0/en/numeric-types.html

Du bist da in der Spalte verrutscht... TinyINT sind 8bit - dementsprechend hast du einen Wertebereich von [-128, 127] resp [0, 255] bei UNSIGNED TINYINT

du kannst in TINYINT immer (unsigned) werte von  0 bis 65535 (2^16 bit) speichern und in INT immer 2^64 bit speichern - du beschränkst lediglich die anzeige auf 3 stellen im dezimalsystem

TINYINT(3) hat nicht den selben Wertebereich wie INT(3). TINYINT(3) kann Zahlen bis 127 resp 255 fassen, während INT(3) Zahlen bis 999 fassen kann.

weiterhin schönen abend...