Würden Sie die Verwendung eines datetime oder eine Zeitstempel Feld und warum (unter Verwendung von MySQL)?
Ich arbeite mit PHP auf der Serverseite.
Würden Sie die Verwendung eines datetime oder eine Zeitstempel Feld und warum (unter Verwendung von MySQL)?
Ich arbeite mit PHP auf der Serverseite.
Zeitstempel in MySQL werden im Allgemeinen verwendet, um Änderungen an Datensätzen zu verfolgen, und werden oft bei jeder Änderung des Datensatzes aktualisiert. Wenn Sie einen bestimmten Wert speichern möchten, sollten Sie ein Datetime-Feld verwenden.
Wenn Sie meinen, dass Sie sich zwischen der Verwendung eines UNIX-Zeitstempels und eines nativen MySQL-Datetime-Feldes entscheiden müssen, wählen Sie das native Format. Auf diese Weise können Sie in MySQL Berechnungen durchführen ("SELECT DATE_ADD(my_datetime, INTERVAL 1 DAY)")
und es ist einfach, das Format des Wertes in einen UNIX-Zeitstempel zu ändern ("SELECT UNIX_TIMESTAMP(my_datetime)")
wenn Sie den Datensatz abfragen, wenn Sie ihn mit PHP bearbeiten wollen.
Ein wichtiger Unterschied besteht darin, dass DATETIME
steht für ein Datum (wie in einem Kalender) und eine Uhrzeit (wie auf einer Wanduhr zu sehen), während TIMESTAMP
stellt einen genau definierten Zeitpunkt dar. Dies kann sehr wichtig sein, wenn Ihre Anwendung mit Zeitzonen arbeitet. Wie lange ist der Zeitpunkt '2010-09-01 16:31:00' her? Das hängt davon ab, in welcher Zeitzone Sie sich befinden. Für mich ist es erst ein paar Sekunden her, für Sie kann es ein Zeitpunkt in der Zukunft sein. Wenn ich 1283351460 Sekunden seit '1970-01-01 00:00:00 UTC' sage, wissen Sie genau, von welchem Zeitpunkt ich spreche. (Siehe Nirs ausgezeichnete Antwort unten). [Nachteil: gültiger Bereich].
Ein weiterer Unterschied: Abfragen mit "nativer" Datetime werden nicht gecached, Abfragen mit Timestamp hingegen schon.
"Zeitstempel in MySQL werden im Allgemeinen verwendet, um Änderungen an Datensätzen zu verfolgen". Zeitstempel sind viel mächtiger und komplizierter als das, wie MattBianco und Nir sagten. Obwohl der zweite Teil der Antwort sehr gut ist. Es ist wahr, was blivet sagte, und ist ein guter Rat.
In MySQL 5 und höher, TIMESTAMP Werte werden für die Speicherung von der aktuellen Zeitzone in UTC umgewandelt und für den Abruf von UTC in die aktuelle Zeitzone zurückgewandelt. (Dies geschieht nur für den Datentyp TIMESTAMP, und no für andere Typen wie DATETIME).
Standardmäßig ist die aktuelle Zeitzone für jede Verbindung die Zeit des Servers. Die Zeitzone kann für jede Verbindung einzeln eingestellt werden, wie in Unterstützung von MySQL-Zeitzonen .
Diese OReilly-Präsentation ist sehr gut für dieses Thema (PDF sorry) cdn.oreillystatic.com/de/assets/1/event/36/
Es geht auch um die Art des Ereignisses: - Eine Videokonferenz (TIMESTAMP). Alle Teilnehmer sollten einen Verweis auf einen absoluten Zeitpunkt sehen, der an ihre Zeitzone angepasst ist. - Eine lokale Aufgabenzeit (DATETIME), ich sollte diese Aufgabe am 31.03.2014 um 9:00 Uhr erledigen, egal ob ich an diesem Tag in New York oder Paris arbeite. Ich beginne mit der Arbeit um 8:00 Uhr der Ortszeit des Ortes, an dem ich an diesem Tag sein werde.
Ja, und das ist einfach furchtbar. Das DBMS sollte Zeitstempel niemals in irgendeine Richtung konvertieren und auch nicht die aktuelle Systemzeit der DB berücksichtigen. Es sollte einfach den internen Zeitstempel so speichern, wie er ist (ms seit Epoche). Beim Rendern des Wertes (im allerletzten Moment) sollte der Wert in der Zeitzone des Benutzers von der Anwendung dargestellt (!) werden. Alles andere ist einfach nur nervig. Wenn überhaupt, sollte das DBMS explizite Typen für lokale und absolute Zeit unterstützen, wobei "lokal" so etwas wie Ihr Geburtstag oder "Mittag" und "absolut" so etwas wie die Startzeit einer Rakete ist.
Ich verwende immer DATETIME-Felder für alles, was keine Zeilenmetadaten sind (Erstellungs- oder Änderungsdatum).
Als erwähnt in der MySQL-Dokumentation:
Der Typ DATETIME wird verwendet, wenn Sie Werte benötigen, die sowohl Datums- als auch Zeitinformationen enthalten. MySQL ruft DATETIME-Werte im Format 'JJJJ-MM-TT HH:MM:SS' ab und zeigt sie an. Der unterstützte Bereich ist '1000-01-01 00:00:00' bis '9999-12-31 23:59:59'.
...
Der Datentyp TIMESTAMP hat einen Bereich von '1970-01-01 00:00:01' UTC bis '2038-01-09 03:14:07' UTC. Er hat unterschiedliche Eigenschaften, die von der MySQL-Version und dem SQL-Modus abhängen, in dem der Server läuft.
Es ist sehr wahrscheinlich, dass Sie bei der allgemeinen Verwendung von TIMESTAMPs an die untere Grenze stoßen - z. B. beim Speichern von Geburtsdaten.
Können Sie auch die Taste obere leicht begrenzen, wenn Sie im Bankwesen oder in der Immobilienbranche tätig sind... 30-jährige Hypotheken gehen jetzt über 2038 hinaus
Natürlich sollten Sie 64-Bit-Unix-Zeitstempel verwenden. Zum Beispiel in Java, new Date().getTime()
gibt Ihnen bereits einen 64-Bit-Wert.
Keine Ahnung. Es ist ein viel größeres Problem als nur MySQL und es gibt keine einfache Lösung: de.wikipedia.org/wiki/Jahr_2038_Problem Ich glaube nicht, dass MySQL einfach erklären kann, dass Zeitstempel jetzt 64-Bit sind, und davon ausgehen kann, dass alles in Ordnung ist. Sie haben keine Kontrolle über die Hardware.
Die folgenden Beispiele zeigen, wie die TIMESTAMP
Datumstyp die Werte nach Änderung der time-zone to 'america/new_york'
donde DATETIME
ist unverändert.
mysql> show variables like '%time_zone%';
+------------------+---------------------+
| Variable_name | Value |
+------------------+---------------------+
| system_time_zone | India Standard Time |
| time_zone | Asia/Calcutta |
+------------------+---------------------+
mysql> create table datedemo(
-> mydatetime datetime,
-> mytimestamp timestamp
-> );
mysql> insert into datedemo values ((now()),(now()));
mysql> select * from datedemo;
+---------------------+---------------------+
| mydatetime | mytimestamp |
+---------------------+---------------------+
| 2011-08-21 14:11:09 | 2011-08-21 14:11:09 |
+---------------------+---------------------+
mysql> set time_zone="america/new_york";
mysql> select * from datedemo;
+---------------------+---------------------+
| mydatetime | mytimestamp |
+---------------------+---------------------+
| 2011-08-21 14:11:09 | 2011-08-21 04:41:09 |
+---------------------+---------------------+
Ich habe meine Antwort in einen Artikel umgewandelt, damit mehr Leute sie nützlich finden können, MySQL: Datetime vs. Zeitstempel-Datentypen .
Der Hauptunterschied besteht darin, dass DATETIME konstant ist, während TIMESTAMP von der time_zone
Umgebung.
Es ist also nur von Bedeutung, wenn Sie synchronisierte Cluster über Zeitzonen hinweg haben - oder in Zukunft haben werden.
Mit einfacheren Worten: Wenn ich eine Datenbank in Australien habe und einen Abzug dieser Datenbank nehme, um eine Datenbank in Amerika zu synchronisieren/aufzufüllen, dann würde TIMESTAMP aktualisiert, um die Echtzeit des Ereignisses in der neuen Zeitzone widerzuspiegeln, während DATETIME immer noch die Zeit des Ereignisses in der australischen Zeitzone wiedergeben würde. .
Ein großartiges Beispiel für die Verwendung von DATETIME, wo TIMESTAMP hätte verwendet werden sollen, ist Facebook, wo die Server nie ganz sicher sind, wann etwas in den verschiedenen Zeitzonen passiert ist. Einmal hatte ich eine Unterhaltung, bei der die Zeit anzeigte, dass ich auf Nachrichten antwortete, bevor die Nachricht tatsächlich gesendet wurde. (Dies könnte natürlich auch durch eine fehlerhafte Zeitzonenumrechnung in der Nachrichtensoftware verursacht worden sein, wenn die Zeiten gepostet und nicht synchronisiert wurden).
Ich glaube nicht, dass dies eine gute Art des Denkens ist. Ich würde einfach alle Daten in UTC speichern und verarbeiten und dafür sorgen, dass das Frontend sie entsprechend der angegebenen Zeitzone anzeigt. Dieser Ansatz ist einfach und vorhersehbar.
@Kos: Ist das Speichern und Verarbeiten aller Datumsangaben in UTC nicht genau das, was TIMESTAMP intern tut (und dann zur Anzeige der lokalen Zeitzone konvertiert)?
meine lokale Zeitzone? Woher sollte Ihre DB meine Zeitzone kennen? ;-) Normalerweise liegt zwischen der Datenbank und der Benutzeroberfläche eine ganze Menge Arbeit. Ich mache die Lokalisierung erst nach der ganzen Verarbeitung.
CodeJaeger ist eine Gemeinschaft für Programmierer, die täglich Hilfe erhalten..
Wir haben viele Inhalte, und Sie können auch Ihre eigenen Fragen stellen oder die Fragen anderer Leute lösen.
2 Stimmen
Hier finden Sie einige wichtige Informationen codeproject.com/Tipps/1215635/MySQL-DATETIME-vs-TIMESTAMP
11 Stimmen
Wenn Sie möchten, dass Ihre Anwendung im Februar 2038 unterbrochen wird, verwenden Sie timestamp. Prüfen Sie den Datumsbereich.
0 Stimmen
Wenn auch nur die geringste Möglichkeit besteht, dass Ihre Datenbank Werte in einer anderen Zeitzone speichern oder Verbindungen von einer Anwendung in einer anderen Zeitzone empfangen muss, sollten Sie ISO-8601 CHARs für alle wichtigen Zeitstempel verwenden. Siehe diese Frage: stackoverflow.com/questions/40670532/
0 Stimmen
Datetime ist völlig nutzlos . es ist nur ein dummer String. timestamp ist in jeder Hinsicht perfekt sondern sie endet im Jahr 2038.