PHP/Datenbanken - Timestamp oder Date?

Seite 1 von 1 - Forum: Coding Stuff auf overclockers.at

URL: https://www.overclockers.at/coding-stuff/php_datenbanken_timestamp_oder_date_212660/page_1 - zur Vollversion wechseln!

Hi!

Möchte mich nur kurz informieren: Ich sehe immer wieder verschiedenste Ansätze bei der Gestaltung von Datenbanken. Ich verwende recht gerne Timestamps weil ich der Meinung bin, dass damit einfach leichter gerechnet werden kann. Sehe aber immer wieder (auch bei größeren Projekten) den Datetime-Datentyp.
Was bevorzugt ihr und habt ihr einen besonderen Grund dafür?
Betrifft natürlich nicht nur PHP-Programmierer sondern auch alle anderen, die mit dbms arbeiten.

mfg

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.

Kommt drauf an. Für Geburtsdaten z.B. ist DateTime besser, aber wenns nur darum geht, wann eine Zeile eingetragen wird -> Timestamp.

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

Hey vorsicht.

Wie schon kleinerChemiker geschrieben hat kommt das IMMER auf die Anwendung an, ein UNIX Timestamp für etwa ein Geburtsdatum zu verwenden wird nicht viel Freude bereiten weil der ja erst 1970 anfängt und nebenbei auch nur bis 2038 oder so läuft (UNIX doomsday...). Aber wenn es zb. um ein Log geht dann bringt dir DateTime oft nichts, da is besser du nimmst Timestamp.

Lokalisierung ist natürlich kein Thema, weil das DBMS sowieso nicht so abspeichert wie du übergibst sondern brav umrechnet (oder sollte) in UTC, und dann nach Bedarf richtig ausgeben kann.

Zitat von watchout

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

Code:

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

Code:

Found these USE flags for dev-db/postgresql-base-8.3.8:
[snip]
pg-intdatetime : Enable --enable-integer-datetimes configure option, which changes PG to use 64-bit integer for timestamp storage

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 that

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

Zitat von watchout

Das Argument mit der Lesbarkeit find ich ziemlich komisch - lesbar? Wodurch? `cat dbfile`?

Zitat von watchout

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)

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)

<- nutze zu 99,9% timestamp

overclockers.at v4.thecommunity
© all rights reserved by overclockers.at 2000-2025