PHP/Datenbanken - Timestamp oder Date?

Ich bevorzuge Unix-Timestamps (unsigned INT) wo es möglich ist und übernehme einen Großteil des Rechenaufwands in die Programmiersprache. Ist (bei MySQL) in so gut wie jedem Fall performanter.

ich denke auch, auch wenn ich nicht selbst viel programmier, dass wenn es als timestamp verwendet werden soll, dann sollte auch das timestamp-"format" verwendet werden, weil es einfacher zu sortieren ist

für einen output in einer software kann man es ja noch immer umrechnen
für ein abgespeichertes datum ist es wahrscheinlich geschmacksache, ob man es in einem datetime format abspeichert oder es auch umrechnen lässt -> vorteil dabei wäre auch hier, dass man lokalisierte fassungen von benutzerumgebungen nur durch die "umrechnung" anbieten kann, die db aber allgemein gültig ist

Zitat von watchout

[…] und nebenbei auch nur bis 2038 oder so läuft (UNIX doomsday...)[…].

Huh?

Code:

colo@zealot ~ $ date --date "Now + 100000 Years" +%s
3156956032147

Bis 2038 wird man ja hoffentlich keine 32Bit-Architekturen mehr verwenden

Wir (in meiner früheren Firma) haben Daten (also Datümer in diesem Fall, aber das Wort gibts ja nicht) als Integer gespeichert - und zwar in der Form Jahr*10000+Monat*100+Tag.

Vorteil: Das funktioniert mit jeder Programmiersprache, mit jedem Datenbank-API, mit jeder Datenbank, mit jeder Ländereinstellung usw. immer gleich. Ein unschätzbarer Vorteil, wenn man mal mit den verschiedenen Varianten von Formatierungen herumgeeiert hat, die dann plötzlich beim Kunden nicht mehr funktionieren, nur weil der irgendwelche anderen Locale-Settings hat.

Zusätzlich bleibt das Datum für Menschen lesbar (20091215), und die Sortierung stimmt.

Nachteil: Man kann auch unsinnige Daten eintragen (60.35.2009), und man kann nicht direkt in der Datenbank mit den Werten rechnen.

Zitat von COLOSSUS

Huh?

Code:

colo@zealot ~ $ date --date "Now + 100000 Years" +%s
3156956032147

Bis 2038 wird man ja hoffentlich keine 32Bit-Architekturen mehr verwenden

Und in welchen Anwendungsfällen speicherst du nur das aktuelle Datum/Uhrzeit und interessierst dich weder für Zukunft noch Vergangenheit?
Willst du heute den Wochentag deines Geburtstags in 40 Jahren berechnen, hast du auf einem 32 Bit System - von denen es heute noch sehr viele gibt, und oft auch selbst wenn der Prozessor schon 64 Bit könnte - wohl ein Problem. Genauso mit langfristigen Projekten oder sagen wir mal Krediten - ein 30 Jahre Kredit ist nicht so unüblich.


@that: es geht um timestamps oder datetime, soll heißen, dir fehlt noch HH*10000+MM*100+SS*1 und dem Rest fehlen 4 Nullen...
Das Argument mit der Lesbarkeit find ich ziemlich komisch - lesbar? Wodurch? `cat dbfile`? ich bezweifle mal dass du damit einen Integer-Wert erkennst, und in jedem anderen Fall liefert das DBMS für DateTime oder Timestamp einen hübschen String zurück der wesentlich besser lesbar wäre als etwa 20091211112009 (wie spät ist es?). Wer das Datum per Programm weiterverarbeiten muss kann ja auch - absolut unabhängig von jeglichem Locale - das Ausgabeformat spezifizieren (und sollte das ja auch tun), wenn nicht sowieso eine Sprache verwendet wird die "hoch" genug ist wo dann die jeweilige Library sowieso schon direkt ein DateTime Objekt zurückgibt welches alle notwendigen Methoden bereitstellt.

Und wenn die Sortierung nach Datum nicht funktioniert... würde ich das DBMS wechseln

Dafür gibts halt das DAO Design Pattern

und zu timestamps:

Code:

mysql> create table timestamp (stamp timestamp, datum datetime);
Query OK, 0 rows affected (0.35 sec)

mysql> insert into timestamp values (now(), now());
Query OK, 1 row affected (0.02 sec)

mysql> select * from timestamp;
+---------------------+---------------------+
| stamp               | datum               |
+---------------------+---------------------+
| 2009-12-15 12:25:07 | 2009-12-15 12:25:07 | 
+---------------------+---------------------+
1 row in set (0.00 sec)

also ich find das is gut lesbar