Mein Grund dafür ist, dass Daten, die als Datumsobjekte in einer beliebigen Datenbank gespeichert sind, dazu neigen, in einem bestimmten Format geschrieben zu werden, was sich sehr von dem unterscheiden kann, was Sie dem Benutzer am Frontend präsentieren müssen. Ich denke auch, dass es besonders hilfreich ist, wenn Ihre Anwendung Informationen aus verschiedenen Arten von Datenspeichern sammelt. Ein gutes Beispiel wäre der Unterschied zwischen einem MongoDB- und SQL-Datumsobjekt.
Allerdings weiß ich nicht, ob dies empfohlene Praxis ist. Soll ich Daten weiterhin als Longs (Zeit in Millisekunden) oder als Datumsobjekte speichern?
Ich kann in Bezug auf MongoDB nicht dafür sprechen, aber in der SQL-Datenbank, nein, es ist keine Best Practice. Das bedeutet nicht, dass es nicht gelegentlich einen Anwendungsfall gibt, sondern "best practice", nein.
Speichern Sie sie als Daten und rufen Sie sie als Daten ab. Am besten ist es, wenn Sie Ihre Datenbank so einrichten, dass sie als UTC (lose, "GMT") gespeichert wird, so dass die Daten portabel sind und Sie je nach Bedarf unterschiedliche lokale Zeiten verwenden können (z. B. wenn die Datenbank von geografisch unterschiedlichen Benutzern verwendet wird). und behandelt alle Konvertierungen von UTC zur lokalen Zeit in der Anwendungsschicht (z. B. über Calendar oder eine Drittanbieter-Datumsbibliothek).
Das Speichern von Datumsangaben als Zahlen bedeutet, dass Ihre Datenbank schwer zu melden ist, Ad-hoc-Abfragen dagegen laufen usw. Ich habe diesen Fehler einmal gemacht, ich wiederhole es nicht ohne wirklich guten Grund . : -)
Es kommt sehr auf Folgendes an:
Der dritte Punkt ist wahrscheinlich der wichtigste. Denken Sie darüber nach, was die Werte, die Sie speichern möchten, wirklich bedeuten. Obwohl du eindeutig Noda Time nicht benutzt, hoffentlich mein Benutzer Anleitung Seite zu wählen, welche Noda Time Typ zu verwenden basierend auf Ihren Eingabedaten kann Ihnen helfen, darüber klar zu denken.
Wenn Sie nur sind, die Java jemals verwenden, und Ihre Datenbank keine besonders gute Unterstützung für Datums- / Uhrzeittypen bietet und Sie nur versuchen, sie darzustellen ein "instant in time" (anstatt, sagen wir, ein Moment in einer bestimmten Zeitzone, oder ein lokales Datum / Zeit mit einem Offset oder nur ein lokales Datum / Zeit oder nur ein Datum ...), und Sie ' Es ist bequem, Diagnose-Tools zu schreiben, um Ihre Daten in besser lesbare Formulare zu konvertieren - dann ist das Speichern von long sinnvoll. Aber das ist eine ziemlich lange Liste von "if" s.
Wenn Sie eine Datumsmanipulation in der Datenbank durchführen möchten - z. Fragen Sie nach allen Werten, die am ersten Tag des Monats auftreten - dann sollten Sie wahrscheinlich einen Datum / Uhrzeit-Typ verwenden, der in der Zeitzone vorsichtig ist. (Meiner Erfahrung nach sind die meisten Datenbanken zumindest schockierend, wenn es um ihre Datums- / Zeittypen geht.)
Im Allgemeinen sollten Sie einen beliebigen Typ verwenden, der alle Ihre Anforderungen erfüllen kann und die natürliche Darstellung für diese bestimmte Umgebung darstellt. In einer Datenbank mit einem Datums- / Uhrzeittyp, der bei der Interaktion mit Ihnen keine Probleme verursacht (z. B. willkürliche Zeitzonenumrechnungen), verwenden Sie diesen Typ. Es wird alle möglichen Dinge einfacher machen.
Der Vorteil der Verwendung einer "primitiveren" Darstellung (z. B. einer 64-Bit-Ganzzahl) liegt genau darin, dass die Datenbank nicht damit herumspielen wird. Sie verbergen effektiv die Bedeutung der Daten aus den Datenbanken, mit all den normalen Vor- und Nachteilen (meistens Nachteile) dieses Ansatzes.
Es hängt von verschiedenen Aspekten ab. Wenn der Standard "Sekunden seit Epoche" verwendet wird und jemand nur ganzzahlige Genauigkeit verwendet, sind seine Daten auf den Zeitraum von 1970-2038 beschränkt.
Aber es gibt auch ein Genauigkeitsproblem. Zum Beispiel ignoriert Unix-Zeit Schaltsekunden . Jeder Tag hat die gleiche Anzahl von Sekunden. Wenn Sie also Zeitdeltas zwischen Unix-Zeit berechnen, erhalten Sie einen Fehler.
Aber die wichtigere Sache ist, dass Sie davon ausgehen, dass alle Ihre Daten vollständig bekannt sind , da Ihre Darstellung nicht die Möglichkeit hat, nur halb festgelegte Daten zu halbieren. In der Realität gibt es viele Ereignisse, die Sie nicht mit einer Sekunde (oder sogar ms) Präzision kennen. Es ist also ein Merkmal, wenn eine Darstellung es ermöglicht, z. nur eine Tag Genauigkeit. Im Idealfall würden Sie Daten mit ihren Präzisionsinformationen speichern.
Außerdem sagen Sie, dass Sie eine Kalenderanwendung erstellen. Es gibt Zeit, aber auch Ortszeit. Häufig benötigen Sie beide Informationen verfügbar. Wenn Sie Überschneidungen planen, können Sie dies natürlich am besten in einer synchronisierten Zeit tun, so lange wird hier gut sein. Wenn Sie jedoch auch sicherstellen möchten, dass Sie keine Ereignisse außerhalb von 9-20 h Ortszeit planen, müssen Sie auch Zeitzoneninformationen erhalten . Für alles, das sich über mehr als einen Standort erstreckt, müssen Sie die Zeitzone in Ihre Datumsdarstellung einfügen. Angenommen, Sie können einfach alle Daten, die Sie sehen, in Ihre aktuelle Ortszeit konvertieren, ist ziemlich naiv.
Beachten Sie, dass Datumsangaben in SQL zu ungewöhnlichen Situationen führen können. Einer meiner Favoriten ist die folgende MySQL Absurdität :
%Vor% darf Datensätze zurückgeben, die das Datum 0000-00-00 00:00:00 haben, obwohl dies das gängige Verständnis von Logik verletzt.
Da diese Frage mit MongoDB getaggt ist: MongoDB speichert keine Daten in String oder was nicht, sie speichern sie tatsächlich als long ( Ссылка ):
Ein BSON Date-Wert speichert die Anzahl der Millisekunden seit der Unix-Epoche (1. Januar 1970) als 64-Bit-Integer. v2.0 +: diese Zahl ist signiert, so dass Daten vor 1970 als negative Zahlen gespeichert werden.
Da MongoDB keine unmittelbaren Pläne hat, die komplexen Funktionen zur Datumsverarbeitung zu verwenden (wie nur Jahr für Abfragen zu erhalten), dass SQL innerhalb der Standardabfrage keinen wirklichen Nachteil hat, könnte es tatsächlich die Größe Ihrer Indizes und Ihres Speichers reduzieren / p>
Es gibt eine Sache, die hier zu berücksichtigen ist, das Aggregations-Framework: Ссылка dort sind seltsame und wunderbare Dinge, die Sie nur mit dem unterstützten BSON-Datentyp in MongoDB erreichen können, jedoch hängt es davon ab, ob dies für Sie von Bedeutung ist.
Sehen Sie, dass Sie die Aggregation Frameworks-Funktionen benötigen? Oder wäre die Unterbringung des zusätzlichen Objektkopfes ein Schmerz?
Meine persönliche Meinung ist, dass der BSON-Datentyp ein so kleines Objekt ist, dass das Speichern eines Dokuments ohne dieses ohne erkennbaren Grund das gesamte System und seine zukünftige Kompatibilität beeinträchtigen würde. Also, ja, ich würde den BSON-Datumstyp eher als einen langen verwenden, und ich würde es als gute Praxis betrachten, dies zu tun.
Es hängt von verschiedenen Aspekten ab. Wenn der Standard "Sekunden seit Epoche" verwendet wird und jemand nur ganzzahlige Genauigkeit verwendet, sind seine Daten auf den Zeitraum von 1970-2038 beschränkt.
Aber es gibt auch ein Genauigkeitsproblem. Zum Beispiel ignoriert Unix-Zeit Schaltsekunden . Jeder Tag hat die gleiche Anzahl von Sekunden. Wenn Sie also Zeitdeltas zwischen Unix-Zeit berechnen, erhalten Sie einen Fehler.
Aber die wichtigere Sache ist, dass Sie davon ausgehen, dass alle Ihre Daten vollständig bekannt sind , da Ihre Darstellung nicht die Möglichkeit hat, nur halb festgelegte Daten zu halbieren. In der Realität gibt es viele Ereignisse, die Sie nicht mit einer Sekunde (oder sogar ms) Präzision kennen. Es ist also ein Merkmal, wenn eine Darstellung es ermöglicht, z. nur eine Tag Genauigkeit. Im Idealfall würden Sie Daten mit ihren Präzisionsinformationen speichern.
Außerdem sagen Sie, dass Sie eine Kalenderanwendung erstellen. Es gibt Zeit, aber auch Ortszeit. Häufig benötigen Sie beide Informationen verfügbar. Wenn Sie Überschneidungen planen, können Sie dies natürlich am besten in einer synchronisierten Zeit tun, so lange wird hier gut sein. Wenn Sie jedoch auch sicherstellen möchten, dass Sie keine Ereignisse außerhalb von 9-20 h Ortszeit planen, müssen Sie auch Zeitzoneninformationen erhalten . Für alles, das sich über mehr als einen Standort erstreckt, müssen Sie die Zeitzone in Ihre Datumsdarstellung einfügen. Angenommen, Sie können einfach alle Daten, die Sie sehen, in Ihre aktuelle Ortszeit konvertieren, ist ziemlich naiv.
Beachten Sie, dass Datumsangaben in SQL zu ungewöhnlichen Situationen führen können. Einer meiner Favoriten ist die folgende MySQL Absurdität :
%Vor%darf Datensätze zurückgeben, die das Datum %code% haben, obwohl dies das gängige Verständnis von Logik verletzt.
Mein Grund dafür ist, dass Daten, die als Datumsobjekte in einer beliebigen Datenbank gespeichert sind, dazu neigen, in einem bestimmten Format geschrieben zu werden, was sich sehr von dem unterscheiden kann, was Sie dem Benutzer am Frontend präsentieren müssen. Ich denke auch, dass es besonders hilfreich ist, wenn Ihre Anwendung Informationen aus verschiedenen Arten von Datenspeichern sammelt. Ein gutes Beispiel wäre der Unterschied zwischen einem MongoDB- und SQL-Datumsobjekt.
Allerdings weiß ich nicht, ob dies empfohlene Praxis ist. Soll ich Daten weiterhin als Longs (Zeit in Millisekunden) oder als Datumsobjekte speichern?
Da diese Frage mit MongoDB getaggt ist: MongoDB speichert keine Daten in String oder was nicht, sie speichern sie tatsächlich als long ( Ссылка ):
Ein BSON Date-Wert speichert die Anzahl der Millisekunden seit der Unix-Epoche (1. Januar 1970) als 64-Bit-Integer. v2.0 +: diese Zahl ist signiert, so dass Daten vor 1970 als negative Zahlen gespeichert werden.
Da MongoDB keine unmittelbaren Pläne hat, die komplexen Funktionen zur Datumsverarbeitung zu verwenden (wie nur Jahr für Abfragen zu erhalten), dass SQL innerhalb der Standardabfrage keinen wirklichen Nachteil hat, könnte es tatsächlich die Größe Ihrer Indizes und Ihres Speichers reduzieren / p>
Es gibt eine Sache, die hier zu berücksichtigen ist, das Aggregations-Framework: Ссылка dort sind seltsame und wunderbare Dinge, die Sie nur mit dem unterstützten BSON-Datentyp in MongoDB erreichen können, jedoch hängt es davon ab, ob dies für Sie von Bedeutung ist.
Sehen Sie, dass Sie die Aggregation Frameworks-Funktionen benötigen? Oder wäre die Unterbringung des zusätzlichen Objektkopfes ein Schmerz?
Meine persönliche Meinung ist, dass der BSON-Datentyp ein so kleines Objekt ist, dass das Speichern eines Dokuments ohne dieses ohne erkennbaren Grund das gesamte System und seine zukünftige Kompatibilität beeinträchtigen würde. Also, ja, ich würde den BSON-Datumstyp eher als einen langen verwenden, und ich würde es als gute Praxis betrachten, dies zu tun.
Es kommt sehr auf Folgendes an:
Der dritte Punkt ist wahrscheinlich der wichtigste. Denken Sie darüber nach, was die Werte, die Sie speichern möchten, wirklich bedeuten. Obwohl du eindeutig Noda Time nicht benutzt, hoffentlich mein Benutzer Anleitung Seite zu wählen, welche Noda Time Typ zu verwenden basierend auf Ihren Eingabedaten kann Ihnen helfen, darüber klar zu denken.
Wenn Sie nur sind, die Java jemals verwenden, und Ihre Datenbank keine besonders gute Unterstützung für Datums- / Uhrzeittypen bietet und Sie nur versuchen, sie darzustellen ein "instant in time" (anstatt, sagen wir, ein Moment in einer bestimmten Zeitzone, oder ein lokales Datum / Zeit mit einem Offset oder nur ein lokales Datum / Zeit oder nur ein Datum ...), und Sie ' Es ist bequem, Diagnose-Tools zu schreiben, um Ihre Daten in besser lesbare Formulare zu konvertieren - dann ist das Speichern von %code% sinnvoll. Aber das ist eine ziemlich lange Liste von "if" s.
Wenn Sie eine Datumsmanipulation in der Datenbank durchführen möchten - z. Fragen Sie nach allen Werten, die am ersten Tag des Monats auftreten - dann sollten Sie wahrscheinlich einen Datum / Uhrzeit-Typ verwenden, der in der Zeitzone vorsichtig ist. (Meiner Erfahrung nach sind die meisten Datenbanken zumindest schockierend, wenn es um ihre Datums- / Zeittypen geht.)
Im Allgemeinen sollten Sie einen beliebigen Typ verwenden, der alle Ihre Anforderungen erfüllen kann und die natürliche Darstellung für diese bestimmte Umgebung darstellt. In einer Datenbank mit einem Datums- / Uhrzeittyp, der bei der Interaktion mit Ihnen keine Probleme verursacht (z. B. willkürliche Zeitzonenumrechnungen), verwenden Sie diesen Typ. Es wird alle möglichen Dinge einfacher machen.
Der Vorteil der Verwendung einer "primitiveren" Darstellung (z. B. einer 64-Bit-Ganzzahl) liegt genau darin, dass die Datenbank nicht damit herumspielen wird. Sie verbergen effektiv die Bedeutung der Daten aus den Datenbanken, mit all den normalen Vor- und Nachteilen (meistens Nachteile) dieses Ansatzes.
Ich halte es nicht für eine bewährte Methode, Daten so lange zu speichern, weil dies bedeuten würde, dass Sie keine der datumsspezifischen Abfragen durchführen könnten. wie:
%Vor%Wir sind auch nicht in der Lage, das Datum Monat des Jahres aus der Tabelle mit SQL-Abfragen leicht zu bekommen.
Es ist besser, einen einzelnen Datumsformatkonverter in der Java-Ebene zu verwenden und das Datum in dieses umzuwandeln und ein einziges Format in der gesamten Anwendung zu verwenden.
Ich kann in Bezug auf MongoDB nicht dafür sprechen, aber in der SQL-Datenbank, nein, es ist keine Best Practice. Das bedeutet nicht, dass es nicht gelegentlich einen Anwendungsfall gibt, sondern "best practice", nein.
Speichern Sie sie als Daten und rufen Sie sie als Daten ab. Am besten ist es, wenn Sie Ihre Datenbank so einrichten, dass sie als UTC (lose, "GMT") gespeichert wird, so dass die Daten portabel sind und Sie je nach Bedarf unterschiedliche lokale Zeiten verwenden können (z. B. wenn die Datenbank von geografisch unterschiedlichen Benutzern verwendet wird). und behandelt alle Konvertierungen von UTC zur lokalen Zeit in der Anwendungsschicht (z. B. über %code% oder eine Drittanbieter-Datumsbibliothek).
Das Speichern von Datumsangaben als Zahlen bedeutet, dass Ihre Datenbank schwer zu melden ist, Ad-hoc-Abfragen dagegen laufen usw. Ich habe diesen Fehler einmal gemacht, ich wiederhole es nicht ohne wirklich guten Grund . : -)
IMHO, Speichern von Daten in DB ist am besten, wenn Sie Strings verwenden können. Vermeiden Sie daher unnötige Daten auf dem Server, wenn Sie nicht alle Felder im Kalender benötigen. Es gibt eine Menge Daten im Kalender und jede Instanz von Calender ist auch ziemlich schwer.
So speichern Sie es als String, mit nur erforderlichen Daten und konvertieren Sie es zurück in den Kalender, wann immer Sie sie brauchen und verwenden Sie sie.
IMHO, Speichern von Daten in DB ist am besten, wenn Sie Strings verwenden können. Vermeiden Sie daher unnötige Daten auf dem Server, wenn Sie nicht alle Felder im Kalender benötigen. Es gibt eine Menge Daten im Kalender und jede Instanz von Calender ist auch ziemlich schwer.
So speichern Sie es als String, mit nur erforderlichen Daten und konvertieren Sie es zurück in den Kalender, wann immer Sie sie brauchen und verwenden Sie sie.