[php] [1/2 OT] Datum und Zeit in MySQL

[Yannik Hampe]

Martin Spuetz wrote:
> Sebastian Mendel wrote:
>>> Wie haltet ihr das in euren Applikationen?
>> ich verwende immer den entsprechenden Datentyp also DATETIME für Datum +
>> Zeit, DATE für Datum, TIME für eine Periode, usw. ...
>>
>> davon ausgehend das MySQL mit den Werten effizienter umgehen kann wenn es
>> weiß was es für Werte sind und dazugehörige Funktionen und Indizierungen
>> darauf optimiert sind ... aber wer weis das schon ... ;-)

Ich schätze mal ein INT ist schneller. Einfach weil er kleiner ist, als 
ein Datetime. 4 Byte vs. 8 Byte. Besonders auf 32 Bit Systemen ist der 
INT von Vorteil... Aber der Unterschied sollte so minimal sein, dass es 
wirklich nur ein Kriterium ist, wenn einem sonst die Kriterien 
ausgegangen sind ;-).
> 
> Das ist die Frage, oft geht es ja um sowas wie anzeigen von / bis. Ist
> da jetzt ein:
> 
> von = '0000-00-00' || von <= NOW()
> 
> oder ein:
> 
> von = 0 || von <= $time
> 
> schneller?

Das hängt davon ab, was dein $time ist. Wenn du $_SERVER['REQUEST_TIME'] 
verwendest, ist dies möglicherweise minimal schneller. Allerdings macht 
dies wohl eher ein tausendstel oder weniger der Zeit aus, die dein Query 
braucht um sich auszuführen. Das ist wirklich der falsche Punkt für's 
große Kopfzerbrechen ;-).

Ansonsten ist der Query-Optimierer von MySQL schon recht schlau. Also 
der Aufruf NOW() wird zum beispiel nur einmal aufgerufen und dann wird 
das Ergebnis für alle Tests gecacht. Ich schätze mal, dass dies den 
String '0000-00-00' auch betrifft. (Ansonsten hoffe ich nurnoch, dass du 
in der Realität kein oder (||) verwendest um solche Tests anzustellen. 
Und das "von" auch mit einem größer-gleich-Operator auf 0 prüfst ;-).
Geht natürlich in SQL auch schön übersichtlich mit
von BETWEEN 0 AND UNIX_TIMESTAMP()
Wenn deine Timestamps da nicht reinpassen ist es allerdings schon 
traurig. Die Verwenbarkeit von timestamps wird schliesslich durch ihren 
kleinen Geltungsberich (1970-2038) so begrentzt...
> 
> In den häufigsten Fällen brauche ich sowieso Timestamps in der
> Anwendungen und so speichere ich die dann auch als int(11) unsigned in
> der Datenbank. Ein UNIX_TIMESTAMP()/FROM_UNIXTIME() bei den Queries ist
> bestimmt mehr overhead...

Ein UNIX_TIMESTAMP() sollte - wie gesagt - gecacht werden. Es sei denn 
natürlich da steht was drin (UNIX_TIMESTAMP(date)) und da gebe ich dir 
Recht: Es ist overhead, der einfach überflüssig ist. Dann nimmt man 
lieber gleich den Datentyp, den man am Ende auch haben will. So 
vermeidet man auch Probleme, die bei der Konvertierung auftreten, womit 
man nicht rechnet (zum Beispiel wegen des 2038-Problems des Timestamps). 
Aber viel Overhead sollte es nicht sein. Aber probier es doch mal aus... 
Mach ein paar Benchmarks. Es fragt sich zwar in wieweit die Ergebnisse 
in der Realität verwendbar ist (schaltest du den Query-cache ab, hast du 
eine unrealistische Situation als Grundlage für deine Tests. Lässt du 
ihn an bewirkt der Query-cache möglicherweise andere Dinge als in der 
Realität etc...)
> 
> Besten Grüße,
> Martin

Yannik