MySQL: Zahlen als INT oder (VAR)CHAR?
 

Hallo zusammen,

hat jemand Erfahrung mit der Speicherung von Zahlen in einer MySQL-Datenbank?

Konkret geht es darum, einen Zeitstempel (Timestamp) oder aber einen Bool'schen Wert (0 oder 1) zu speichern.

Für den Zeitstempel habe ich bislang immer VARCHAR mit maximaler Länge 11 verwendet, um dem Jahr-2038-Problem zumindest theoretisch aus dem Weg zu gehen. Ansonsten bräuchte man da mindestens INT (unsigned), inklusive den Folgen in 28 Jahren.

Für letzteres (0 oder 1) wäre selbst TINYINT mit dem Wertebereich von -128 bis 127 bzw. 0 bis 255 viel zu groß ausgelegt. Nimmt man dagegen CHAR(1), so ist dieser Wertebereich auch für Buchstaben ausgelegt, was ja nicht Sinn der Sache ist.

Was ist hier besser geeignet? Zahlen als Text speichern oder trotzdem auf die eingebauten Zahlentypen zurückgreifen? Komme mir dabei ja schon ein bisschen vor, als würde ich MySQL vergewaltigen :D

lg

Für Timestamps gibt es einen Datentyp MySQL :: MySQL 5.1 Referenzhandbuch :: 11.3.1 Die DATETIME-, DATE- und TIMESTAMP-Typen
Für einen boolschen Wert bietet sich enum an
MySQL :: MySQL 5.1 Referenzhandbuch :: 11.4.4 Der Spaltentyp ENUM

Ja ich ich teile deine Bedenken mit der Vergewaltigung. ;)

Was spricht gegen INT für den Unix-Timestamp?

Für boolsche Werte würde ich wenn möglich BOOLEAN verwenden, oder wenn nicht möglich (zum Beispiel bei MySQL) ENUM, dort kannst du die erlaubten Werte fest angeben.

@protonenbeschleuniger
Ich denke er meint mit Timestamp einen Unix-Timestamp, dafür gibt es afaik keinen "passenden" Datentyp.

Ja stimmt, der Timestamp ist Quark. Vielleicht noch ein unsigned vor dem int?

EDIT: Oder man wandelt den Timestamp in ein Zeitformat um

Danke für eure Antworten.

Mir ging es auch sehr stark um den Speicherverbrauch.
Fall 1:
- Boolean in MySQL entspricht TINYINT, 1 Byte, geht bis 255.
- ENUM mit bis zu 255 verschiedenen Werten (so ein Zufall!), 1 Byte.

Also hier kein Unterschied, außer dass sicher nur verwendete Werte wie 0 oder 1 vorkommen. Also liegt hier der Vorteil bei ENUM.

Für den Timestamp möchte ich bewusst keine vorhandenen MySQL-Datentypen wie DATETIME verwenden, da man mit PHP mit diesen wesentlich schlechter umgehen kann als mit Timestamps (beispielsweise seien da mal date() oder strftime() genannt).
unsigned INT geht eben bis zu jenem Jahr 2038. ;) BIGINT würde das Problem lösen, braucht aber nun mal doppelt so viel Speicher (8 Bytes).
Ich denke, in diesem Bereich werde ich in Zukunft normal auf INT setzen. VARCHAR belegt für 10 Stellen 11 Bytes und ist damit eigentlich aus dem Rennen.
Oder?

Kann vielleicht jemand eine Aussage zur Performance machen? Die Timestamp-Felder werden häufig zum Sortieren und Filtern verwendet.

Genau die gleichen Funktionen (oder ähnliche, die u.U. anders heißen) kannst du auch in mysql verwenden um das Datum in das Format umzuwandeln das du haben möchtest. Vom Speicherverbrauch tut sich da wohl nicht viel, aber prinzipiell sind Zahlen da im Vorteil, da char fast immer in varchar umgewandelt wird. Wenn du aber mal nach dem Feld sortieren willst (oder z.b. Abfragen nach Monat oder Jahr gruppieren) ist das Datum sicher im Vorteil

Da zeigen sich mE mal wieder die Unzulänglichkeiten der verwendeten "Porgrammiersprachen".
Wozu soll mir eine Datenbank einen Datentyp vorgeben bzw wozu benötigt die diesen ?

Doch eigentlich nur zum Indizieren (den Index brauche ich für eine schnelle Suche).
Dann sollte ein Datentyp auch nur dort zum Tragen kommen (und auch nur, um 2 Werte
zu vergleichen).

Stattdessen geht sofort wieder die Gurkerei mit den allseits so beliebten Interpretern
wie PHP los. Es ist doch meine Sache als Programmierer was ich mit zB 4 Bytes anfange.
Das kann für mich ein String oder eine int sein oder irgendetwas anderes.
Meine Sache und kann je nach Abfrage radikal wechseln.

Schaut euch mal Datenbanken wie Btrieve an - hochinteressant und völlig frei
in der Anwendung. Dem Mainstream folgend gibt es natürlich auch einen SQL-Aufsatz.

Und auch im Web gibt es mehr wie immer nur das klägliche PHP.

Bei Datenbanken kann ich es nachvollziehen. Aber warum sollte mir eine Programmiersprache vorschrieben, was für ein Datentyp eine Variabel haben soll? Das ist unzulänglich.

@Scheppertreiber:
Dass du PHP nicht magst ist ja schon oft genug rübergekommen. Aber wie so viele andere Programmier- bzw. Skriptsprachen hat auch diese ihre Vor- und Nachteile.
Genauso wie eine dynamische Typisierung einen angenehmeren bzw. freieren Programmierstil erlaubt, gleichzeitig aber mögliche Fehlerquellen mit sich bringt. Die feste Vorgabe eines Types kann nützlich sein, um ungültige Wertebereiche (siehe Bool'sche Variable) auszuschließen, kann aber auch mit gängigen Funktionen z.B. in PHP geprüft werden.

Zumal hat das Problem hier ganz klar nichts mit dem PHP-Interpreter zu tun. :|

http://www.lowbird.com/data/images/2...rl-failure.jpg

Ich möchte generell die Daten so aus einer Datenbank herausbekommen wie ich
sie dem DBMS übergeben habe. Ich bin letzte Woche über so einen Macke in SQLite
gestolpert:

Ich hatte eine Spalte als "text" deklariert und dort nur Mandantennummern mit
Vornullen eingefügt. Irgendwann hat SQLite beschlossen, weil nur Zahlen in der
Spalte stehen müsse es sich um int handeln und die Vornullen rausgeworfen.

Gaaanz toll ... :twisted: