nicht angemeldet
Hi!
Der gleiche Speicherverbrauch ((4-Byte-)Integer und TIMESTAMP) unterstützt meine obige Annahme, die angenehmere Verarbeitung aufgrund der "Außenwirkung" will man ebenfalls nicht missen. Wie die Datümser™ intern gespeichert werden, kann ja egal sein, wie sie behandelt werden, ist es nicht. Um eine Formatierung zu bekommen, die für einen bestimmten Anwendungsfall erforderlich ist, kann man entspechende Funktionen verwenden (zum Beispiel DATE_FORMAT() und auch UNIX_TIMESTAMP()).
Argumentierst du jetzt pro TIMESTAMP oder pro INTEGER? Zwischen den Zeilen interpretere ich ersteres...
Ich argumentiere pro TIMESTAMP mit dem vielleicht unnützen Hintergrundwissen, dass der intern auch nur ein Integer ist. Allerdings kann man aus diesem Wissen ableiten, warum der TIMESTAMP den selben Wertebereichsbedingungen unterliegt wie ein auf Integer basierender Unix-Timestamp. (von 1970 bis ~2038, und wenn man die negativen Werte noch dazunimmt, von ~1901)
Auf den Punkt gebracht:
Wenn du TIMESTAMP statt INTEGER zum speichern deiner Datümser™ benutzt hast du den selben Speicherverbrauch, aber direkten Zugriff auf die Datumsfunktionen. Würdest du INTEGER speichern müsstest du zunächst FROM_UNIXTIME() anwenden um dann etwa YEAR() oder DATE_SUB() nutzen zu können.
Genau. Wobei mir grad noch einfällt, dass TIMESTAMP unter MySQL eigentlich nicht für das Speichern beliebiger Datümser™ vorgesehen ist, sondern eher reinweg als Zeitstempel im eigentlichen Sinne. Denn TIMESTAMP-Spalten haben noch eine eigene Art von Magie eingebaut, die eventuell hinderlich für normale Anwendungen ist. Der bevorzugte Typ für beliebige Datumsangeben sollte DATE(TIME) sein.
Lo!