Ich habe in einem Artikel gelesen, der einige wirklich gute Informationen und Benchmarks zeigt, wie gut die drei verschiedenen MySQL-Speicheroptionen für Datum und Uhrzeit funktionieren.
MySQL DATETIME vs TIMESTAMP vs INT Leistung und Benchmarking mit MyISAM
Beim Lesen des Artikels fangen Sie an, die Idee zu verstehen, dass die Verwendung von Ints nur eine Verschwendung ist, und Sie sollten stattdessen mit den Spaltentypen von MySQL Datetime oder Timestamp gehen.
Gegen Ende des Artikels führt er jedoch einen weiteren Test durch, bei dem keine MySQL-Funktionen verwendet werden, und Sie sehen plötzlich, dass gerade INTs bei der Suche nach Unix-Zeitstempeln <2x> so schnell sind wie die beiden MySQL-Optionen. / p>
So dämmerte es mir plötzlich - duh, was machen PHP-Apps? time ()! Fast jede PHP-Anwendung basiert ihre Logik auf der Unix-Epoche. Das bedeutet, dass die meisten Abfragen nach Ergebnissen in einer bestimmten Zeit auf der Grundlage von time () beginnen und dann in die MySQL-Felder konvertiert werden.
Dies lässt mich folgendes:
Unix-Zeitstempel, die als INTs gespeichert sind schneller, nehmen Sie weniger Platz und arbeiten nativ mit PHP-Zeit () basiert Berechnungen.
MySQL-Datentypen sind besser geeignet für Operationen und Logik aus dem MySQL Seite.
Vorläufig beide Unix And MySQL Zeitstempel funktionieren nur bis 2037, was bedeutet, dass Sie eine verwenden müssen datetime Feld für größere Daten in die Zukunft.
MySQL-Befehle wie date = NOW() können verzögern wenn
Verwenden der Replikation, die Dateninkonsistenzen verursacht.
Wenn wir das auf das wirkliche Leben anwenden, sehen wir diese Antwort dass diese Ergebnisse gegeben, dass die meisten wirklich DBAs eine bessere Engine wie PostgreSQL verwenden würden - gibt es arny
Die meisten Apps, die auf der Ebene der DB-Logik arbeiten würden, würden jedoch wahrscheinlich mit PostgreSQL funktionieren. Das bedeutet, dass alle anderen Programmierer von uns nur MySQL als Speicher für unsere Daten verwenden (Sie wissen, dass es wahr ist), was die Felder so klein hält, dass UNIX INTs tatsächlich so aussehen beste Option.
Also, was denkt ihr?
Sind Zeitstempel wirklich besser für PHP-Anwendungen geeignet als die MySQL-Datumsfelder?
Das Datumsformat von MySQL hat kein Jahr 2038-Problem.
Die Daten von MySQL sind zuverlässig vom Jahr 1000 bis zum Jahr 9999, während Unix-Zeitstempel nach 2038 oder vor 1902 versagen können, wenn nicht alles in Ihrem System 64-Bit ist.
Wenn Sie jedoch PHP verwenden, kann dies problematisch sein: PHP verwendet Unix-Zeitstempel für Datum und Uhrzeit in den meisten seiner Datums- und Zeitfunktionen. Wenn Sie kein 64-Bit-Build verwenden, hat es die gleiche Einschränkung.
Sie würden den Feldtyp verwenden, der für diesen Zweck vorgesehen war.
Wenn es dich interessiert. Das Einfügen eines Datums in ein INT-Feld als Unix-Zeitstempel ist nicht so selbstbeschreibend; Sie können die Daten nicht ansehen, ohne sie in der entsprechenden Weise zu konvertieren. Aber das macht für dich keinen Unterschied.
Die Kehrseite davon ist, dass Sie, wenn Sie PHP benutzen, wissen, dass Sie, sobald Sie die Zeit für PHP haben, diese sowieso wieder in einen Unix-Zeitstempel konvertieren müssen, um etwas Nützliches damit zu tun. Unix-Zeitstempel sind nativ.
Bearbeiten:
Als ich diese Antwort geschrieben habe, habe ich die DateTime-Klasse von PHP nicht verwendet. Wenn Sie die DateTime-Klasse verwenden, müssen Sie keine Unix-Zeitstempel mehr verwenden und die 32- / 64-Bit-Probleme entfernen. Danke an Charles Kommentar unten für den Hinweis auf eine gute Möglichkeit, dies zu verwenden.
Ich bevorzuge es immer, Daten im mySQL-Format zu speichern, da dies die Vergleiche in Ihren Abfragen vereinfacht. mySQL hat auch einige großartige Formatierungsoptionen: Ссылка
Tut mir leid, ich sollte hinzufügen, ich weiß wirklich nicht, um welche Geschwindigkeit es geht, was ein wichtiger Teil Ihrer Frage war.
Ich möchte die gesamte Logik in einer einzigen High-Level-Domain behalten (das ist die in PHP geschriebene App). MySQL ist ein Speicher - so wie es bleiben soll. Ich bevorzuge eine Klasse wie Ссылка und dann - & gt; dump () oder - & gt; get () auf das passende Format sowieso. Es ist viel schneller und einfacher, auf hoher Ebene Manipulationen in der Anwendungsdomäne zu schreiben (und zu erweitern) als mit der statischen mysql-Schnittstelle.
Die PostgreSQL-Schnittstelle bereinigt MySQL. Aber wir reden hier immer noch über MySQL, weil es beliebt ist. Das bringt eine wichtige Überlegung. Wenn Code geschrieben oder Systeme entworfen werden, ist es oft sinnvoll, die Konvention einzuhalten, auch wenn sie weniger recheneffizient ist als andere weniger bekannte Optionen. Dies ist wichtig, weil es eine andere Art von Effizienz begünstigt - Lesbarkeit für andere. Die Ineffizienzen von Lesbarkeit und Verständlichkeit sind häufig mit höheren Geschäftsausgaben (und Zeitaufwand) verbunden als rechnerische Ineffizienzen.
Ich bin aber dafür, INTs zu versuchen. Bitte versuchen Sie es und schreiben Sie über Ihre Ergebnisse.
Prost
Die Verwendung der verschiedenen Zeit- und Datumsformate von MySQL ermöglicht Abfragen, die mit Unix-Zeitstempeln schwierig wären.
Ein Beispiel wäre das Filtern von Daten basierend auf einer bestimmten Woche (Wochennummer) oder die Verwendung eines Werts in der Datenbank nach dem Hinzufügen oder Entfernen eines bestimmten Zeitrahmens.
MySQL hat einige großartige Funktionen für die Zeit- und Datumsmanipulation arbeiten Sie gut mit den Formaten für Datum, Datum und Uhrzeit.
Wir verwenden PHP / MySQL für die meisten unserer Websites und automatisieren die Erstellung von Datenbanken für PHP-Objekte. Der Code für den Wechsel von PHP- zu MySQL-Formaten ist sehr einfach:
%Vor%MySQL zu PHP:
strtotime () für Datetime mktime () für Uhrzeit und Datum
Schöne und offene Frage. Ich sehe, dass Sie ein perfeccionist sind. Ich auch.
Aber wie fast alles in Programmierung und im Leben hängt es davon ab, wie es zu Ihrem Problem passen würde.
Wenn die Leistung wirklich kritisch ist, sollten Sie UNIX-Zeitstempel verwenden.
Aber ich glaube wirklich nicht, dass es so ist. Ich sage dir warum. Es ist, weil ich denselben Standpunkt wie Rasmus Lerdorf teile. PHP ist eine Skriptsprache, die viele Möglichkeiten für kleine und mittlere Unternehmen bietet.
Für wirklich wirklich kritische / große Anwendungen, bei denen Skalierbarkeit und Leistung wirklich wichtig sind, sollten Sie PHP + MySQL überhaupt nicht verwenden.
Java oder C ++ sind die besseren Lösungen. Ich denke, die meisten Leute werden sich fragen "Was ist los mit PHP, dein Bastard ?!". Nun, viele Dinge tatsächlich. Ich habe eine Weile als Performance-Tester gearbeitet und ich sage, dass Entwickler daran denken sollten, dass Ihre Lieblingssprache nicht immer die beste Lösung für jedes Problem ist.
Lass mich dir und ein Beispiel geben. Eine kritische Mathematik / Physik-Anwendung. Brauche einfach eine Nummer für eine Phänomenanalyse. Sie können dies mit Shell Script und C tun. C wird weit besser funktionieren. Sehen Sie, indem Sie die für Ihr Problem am besten geeignete Sprache und Werkzeuge auswählen, ist die Antwort auf Ihre richtige Antwort.
Kommen wir zurück zu MySQL, PHP und den Datentypen. Wenn Sie diese verwenden, Ich nehme an ist die Anwendung nicht so groß und nicht voll mit Geschäftsregeln (wenn es so groß ist, würden Sie einige kompilierte Sprachen in Erwägung ziehen, und wenn es so wichtig ist, sollten Sie es tun Erwägen Sie die Verwendung von PostgreSQL oder Oracle).
Und in diesem Fall kommt es auf die Geschwindigkeit an, mit der die Anwendung aufgebaut wird. Wenn Sie dies tun, sollten Sie Ihre Formularfelder anhand von Datenbankmetadaten erstellen. Dies kann Ihnen helfen, die Formularerstellung zu automatisieren. Und in diesem Fall empfehle ich, native Datenbanktypen zu verwenden.
Wenn Sie anstelle von DATETIME INT verwenden, verlieren Sie die Flexibilität in GROUP nach Datum, Stunde oder Zeit, und nehmen unterschiedliche Manipulationen mit Intervallen vor.
Sie können INT mit der Funktion FROM_UNIXTIME erstellen, aber die Abfrage ist nicht lesbar.
Wenn Sie INT statt DATE verwenden, kostet das Programmieren x3, dann arbeiten Sie mit DATE. Sie gewährleisten, dass die Ausführungszeit nicht ausreicht, um die Programmierkosten zu decken. Hardware ist billiger als komplexe Programmierung.
Sobald wir diesen Fehler gemacht haben und ein Datum in INT haben. Nach einem halben Jahr entscheiden wir uns für 30 Standorte, um die Wartung zu erleichtern.