theHacker

sieht vor lauter Ads den Content nicht mehr
Teammitglied
ID: 69505
L
20 April 2006
22.682
1.316
Hi.

Ich arbeite mit DATETIME-Spalten und mich würde mal interessieren, ob es irgendwelche Gründe gibt,

  • lieber in der DB mittels UNIX_TIMESTAMP() umzurechnen oder
  • stattdessen das in PHP mittels strtotime() zu machen,
wenn man den UNIX-Timestamp braucht?
 
Was machst du wenn MySQL eines Tages die String-Representation eines Datetime in ein Format ändert, welches PHP nicht lesen kann? ;)
 
Ich wollte zwar eher auf ein "x is schneller als y" raus, aber gut, das hat meine Frage auch schon beantwortet :) :biggrin:
 
Was machst du wenn MySQL eines Tages die String-Representation eines Datetime in ein Format ändert, welches PHP nicht lesen kann? ;)

Eigentlich habe ich Zweifel, dass dies geschehen wird, ohne das PHP entsprechend seine Funktion anpasst... würde aber eigentlich auch die Umwandlung innerhalb der Datenbank bevorzugen, nur dass mir da die Argumente für fehlen ;)
 
Momentan kommt ja alles aus ner MySQL Datenbank als String in PHP an :roll:
Ich will nicht wissen, was passiert, wenn sich da mal was dran ändert :ugly:
soweit ich weiß, hat es das glaube ich schon.
Wenn ich mich recht entsinne kommen mit mysqlnd die Daten in den echten PHP-Datentypen an.

Eigentlich habe ich Zweifel, dass dies geschehen wird, ohne das PHP entsprechend seine Funktion anpasst... würde aber eigentlich auch die Umwandlung innerhalb der Datenbank bevorzugen, nur dass mir da die Argumente für fehlen ;)
Die Funktion heisst strtotime und nicht mysqldatestrtotime :ugly:
Es mit strtotime zu machen ist nur ein ugly-Hack und sollte keinesfalls in Erwägung gezogen werden, basta aus :ugly:
 
Ich wuerde mal stark annehmen dass es wenig unterschied macht, DATETIME wird intern als integer abgespeichert, und ich denke auch als integer an die client-library uebergeben, die client library kuemmert sich dann um die interpretation des integers und das generieren des Strings der dann an PHP weitergegeben wird, oder seh ich das stark falsch?
String materialisierung auf'm server macht doch erst sinn wenn der string dann manipuliert wird.

Ich denke es ist reine vorliebe, einfluss auf den speed hat's erst wenn du viel hin und her konvertierst.
 
DATETIME wird intern als integer abgespeichert, und ich denke auch als integer an die client-library uebergeben
nein, die Darstellung von Datetime ist ein String im Format YYYY-MM-DD HH:MM:SS

oder seh ich das stark falsch?
jup :biggrin:

String materialisierung auf'm server macht doch erst sinn wenn der string dann manipuliert wird.
PHP wandelt jeden MySQL-Datentyp in einen String um, da es teilweise die MySQL Datentypen nicht darstellen: Unsigned Integer existieren in PHP nicht, Dezimal-Values beliebiger Länge usw.
 
nein, die Darstellung von Datetime ist ein String im Format YYYY-MM-DD HH:MM:SS

PHP wandelt jeden MySQL-Datentyp in einen String um, da es teilweise die MySQL Datentypen nicht darstellen: Unsigned Integer existieren in PHP nicht, Dezimal-Values beliebiger Länge usw.

Schade dass du dir die Zeit nicht genommen hast meinen Post zu lesen:
It's stored as an 8 byte field. The first 4 bytes stores the number of days since SQL Server's epoch (1st Jan 1900). The second 4 bytes stores the number of milliseconds after midnight.
Und da ich nicht client sonder client library gesagt hab' stimmt meine zweite Aussage auch (grad selber mit Network Dump gecheckt) der transfer von mysql daemon zu client library (php5-mysqli Modul, nicht das PHP script) ist wirklich die interne Darstellung (also wieder 8 byte), was PHP dann danach mit dem Wert macht tut nichts zur Sache Q.E.D. :evil:
 
der transfer von mysql daemon zu client library ist wirklich die interne Darstellung (also wieder 8 byte), was PHP dann danach mit dem Wert macht tut nichts zur Sache Q.E.D. :evil:
wer sagt denn das PHP den Wert verändert? :roll:

die Kommunikation findet immernoch so statt:
Code:
MySQL-Server --> MySQL-Connector --> PHP-MySQL-Library --> PHP-Code

und ich nehme an, dass der MySQL-Connector direkt den Wert umwandelt, natürlich kommuniziert MySQL mit seinem eigenen Connector möglichst effizient, also in der internen Darstellung, gibt die Daten dann aber weiter wie man sie sonst auch sehen würde, es wäre ja absoluter Schwachsinn wenn PHP mit jeder neuen MySQL-Version seinen Code anpassen müsste, um die interne Darstellung der Daten auf die sichtbare zu Übertragung.
Und es hat noch einen kleinen Fehler ;)
Demnach müsste unter Java/PHP/Perl/Python/Ruby die Ausgabe eines Datetime nicht gleich sein, denn jede Library könnte die 8Bit ja anders darstellen: ISO-Schreibweise, enhanced Unix-Timestamp usw.