Datum?

Hm die Umwandlung verlangsamt den Datetime zu nem int bzw. timestamp um 3%!
Und vergesst dabei aber nicht, dass das eine ein 64bit int(geh mal davon aus nach M.R.ers "quote" und das andre nur ein 32bit int is. Dafür sind die 3% sehr gut. Aber ich will ein Projekt sehen, wo man proentual gesehen öffter damit rechnet als es auszugeben! Wenn ich mir hier so dieses Forum angucke, da seh ich verdammt viele formatierte Datume(oO was isn da die Mehrzahl?) Weshalb ich weiterhin jedem Datetime ans herz legen werde und selst benützen werde, wobei ich mir das vielleicht bei meinem Browsergame überlegen müsste wobei hier trozdem dann ein Timestamp benützt werden würde.
 
Benchmarks hin oder her, aber im Alltagsbetrieb wird man nie einen Geschwindigkeitsunterschied feststellen können. Wer nutzt denn PHP und mySQL für irgendwleche Datumsberechungen / -ausgaben bei mehreren Tausend Datensätzen pro Query bzw. extrem vielen Querys pro Sekunde?
Sobald man neben dem Datum noch andere Werte mit ausliest (was ja meistens der Fall seien sollte), ist kein Geschwingkeitsunterschied mehr feststellbar.

Deshalb denke ich, wer seine Datumsangaben als Unixtimestamp und Int speichern will, der soll das tun. Wer aber die mySQL-Datumsfunktionen nutzen will, und auch mit Daten vor dem 1.1.1970 arbeiten will (und das kommt ja durchaus mal vor), der soll sich für DATE / DATETIME / TIMESTAMP entscheiden.
 
Oh doch... und das ist der Grund warum die kein MySQL sondern eine kommerzielle Lösung wie Sybase oder Oracle verwenden..
Da laufen auch keine 0815-Linuxkisten im Hintergrund sondern UNIX-Großrechner (Standard wäre Sun-Kiste mit Solaris und Oracle-DB)
 
Hm ich denke schon dass es was bringt, wenn man nen Query optimiert, der paar hunderttausend x am Tag aufgerufen wird. Vielleicht nicht viel vielleicht auch ned wirklich viel aber ein kleines bischen vielleicht öhm 100 oder 1000 Anfragen mehr? Na gut wird wohl spekulation sein.

Btw: Wenn jetzt noch der Artikel kommt den Lukaz posten wollte hm.
 
TheLightning hat gesagt.:
Oh doch... und das ist der Grund warum die kein MySQL sondern eine kommerzielle Lösung wie Sybase oder Oracle verwenden..
Da laufen auch keine 0815-Linuxkisten im Hintergrund sondern UNIX-Großrechner (Standard wäre Sun-Kiste mit Solaris und Oracle-DB)
Zum Vergrößern anklicken....
Das ist ja wieder was ganz was anderes. Das mySQL solchen Aufgaben nicht mehr gewachsen ist, das ist klar. Aber mit Sicherheit nicht wegen der Performance einer Datums-Umformatierung.
Wie in meinen Benchmarks zu sehen, ist der Unterschied, einen INT auszulesen, und einen DATETIME mit UNIX_TIMESTAMP auszulesen, nicht besonders groß. Meine Abfragen bezogen sich aber auf Tabellen, in denen nur dieser Datumswert gespeichert ist. Bekommt die Tabelle nun noch mehr Spalten, die auch alle abgefragt werden, wird der prozentuale Geschwindigkeitsunterschied zwischen INT und DATETIME noch um viele Größenordnungen geringer.
Da macht es wahrscheinlich mehr aus, ob ich einen Usernamen als VARCHAR(20) oder VARCHAR(18) abspeichere.
 
Oliver Gringel hat gesagt.:
Das ist ja wieder was ganz was anderes. Das mySQL solchen Aufgaben nicht mehr gewachsen ist, das ist klar. Aber mit Sicherheit nicht wegen der Performance einer Datums-Umformatierung.
Wie in meinen Benchmarks zu sehen, ist der Unterschied, einen INT auszulesen, und einen DATETIME mit UNIX_TIMESTAMP auszulesen, nicht besonders groß. Meine Abfragen bezogen sich aber auf Tabellen, in denen nur dieser Datumswert gespeichert ist. Bekommt die Tabelle nun noch mehr Spalten, die auch alle abgefragt werden, wird der prozentuale Geschwindigkeitsunterschied zwischen INT und DATETIME noch um viele Größenordnungen geringer.
Da macht es wahrscheinlich mehr aus, ob ich einen Usernamen als VARCHAR(20) oder VARCHAR(18) abspeichere.
Zum Vergrößern anklicken....

Ich habe die ganze Zeit an SELECTS die über den DATETIME aggieren gedacht.. wenn du dann noch joins drin hast kann das bisschen was für timestamp verantwortlich in summe dann doch schon etwas an einbusen mit sich bringen... :)
 
Bekommt die Tabelle nun noch mehr Spalten, die auch alle abgefragt werden, wird der prozentuale Geschwindigkeitsunterschied zwischen INT und DATETIME noch um viele Größenordnungen geringer.
Zum Vergrößern anklicken....
Wieso sollte das sein? Wenn weitere, in beiden Fällen identische Werte abgefragt werden, so wären diese im mathematischen Sinne bloß „Konstanten“ und entfiehlen so bei einer Gegenüberstellung. D. h. die beiden „Variablen“ INT und DATETIME stünden sich wieder allein gegenüber.
 
Zuletzt bearbeitet:
Um antworten zu können musst du eingeloggt sein.

Neue Beiträge

Zurück