PHP/Oracle: Zeitdarstellung

Question

Haftungsausschluss: Ich bin mir völlig darüber im Klaren, dass die beste Art, die Datum/Zeiten sind entweder Unix-Zeitstempel oder PHPs DateTime Klasse und Oracles DATE Datentyp.

Mit, dass aus dem Weg, ich frage mich, was die am besten geeigneten Datentypen sind (in PHP, sowie Oracle) für die Speicherung von nur Zeit Daten. Ich bin nicht daran interessiert, eine Datum Komponente, sondern nur die Zeit.

Nehmen wir zum Beispiel an, ich hätte eine employee für den ich seinen/ihren typischen Arbeitsplan speichern wollte. Dieser Mitarbeiter könnte von 8:00 bis 17:00 Uhr arbeiten. Es gibt keine Datum Was sollte also verwendet werden, um diese Zeiten zu speichern und darzustellen?

Ich habe verschiedene Optionen in Betracht gezogen:

1. Als Zeichenketten, mit einem Standardformat (wahrscheinlich 24-Stunden HH:MM:SS+Z).
2. Als Zahlen im Bereich 0 <= n < 24, wobei die Nachkommastellen für Minuten/Sekunden stehen (Zeitzonenangaben können nicht gespeichert werden?).
3. Als PHP DateTime und Oracle DATE mit normalisierter/unbenutzter Datumskomponente, z. B. 0001-01-01 .
4. Gleich wie oben, nur mit Unix-Zeitstempeln (PHP integer und Oracle TIMESTAMP ).

Derzeit verwende ich die obige Nummer 3, aber es ärgert mich irgendwie, dass es scheint, als würde ich diese Datentypen missbrauchen. Soweit ich das beurteilen kann, bietet es jedoch die beste Benutzerfreundlichkeit. Vergleiche und Sortierungen funktionieren sowohl in PHP als auch in Unix wie erwartet, die Zeitzonendaten können beibehalten werden, und für die Anzeige der Daten ist eigentlich keine spezielle Manipulation erforderlich.

Übersehe ich etwas, oder gibt es eine geeignetere Methode?

Answer 1

Wenn Sie das Datum überhaupt nicht brauchen, dann brauchen Sie nur die interval day Datentyp. Ich habe das noch nicht wirklich gebraucht, aber folgendes devrait Arbeit:

interval day(0) to second(6)

Answer 2

Die von Ihnen gewählte Option (3) ist die beste.

Oracle verfügt über die folgenden Typen zur Speicherung von Zeiten und Daten:

• Datum
• Zeitstempel (mit (lokaler) Zeitzone)
• Intervall Jahr bis Monat
• Intervall Tag bis Sekunde

Intervall-Datentypen kommen für Sie nicht in Frage, weil Sie sich darum kümmern, wann Sie anfangen und wann Sie aufhören. Sie könnten zwar ein Datum und ein Intervall verwenden, aber das erscheint mir inkonsistent, da Sie immer noch ein "falsches" Datum haben.

Alle anderen von Ihnen genannten Optionen erfordern mehr Arbeit und führen wahrscheinlich auch zu einer geringeren Leistung im Vergleich zum nativen Datumstyp.

Weitere Informationen über Orakel-Datumsarten: http://docs.oracle.com/cd/B19306_01/server.102/b14225/ch4datetime.htm#i1005946

Answer 3

Ich denke, dass die richtige Antwort auf diese Frage ganz davon abhängt, was Sie mit den Daten vorhaben. Wenn Sie vorhaben, Ihre gesamte Arbeit in PHP zu erledigen und nichts in der Datenbank, ist es am besten, die Daten in einem Format zu speichern, das Ihnen bei Ihrer Arbeit in PHP am meisten hilft. Das könnte in der Tat die Speicherung als Strings sein. Das mag für einen DBA grauenhaft klingen, aber Sie dürfen nicht vergessen, dass die Datenbank dazu da ist, Ihrer Anwendung zu dienen. Wenn Sie andererseits viele Vergleiche in der Datenbank mit ausgefallenen Abfragen durchführen, sollten Sie darauf achten, alles in der Datenbank in einem Format zu speichern, das Ihre Abfragen möglichst effizient macht.

Bei Aufgaben wie der Berechnung von Arbeitsstunden bei schweren Lasten kann die Konvertierung in ein Dezimalformat die Berechnungen erleichtern, bevor eine endgültige Konvertierung zurück in Stunden:Minuten erfolgt. Eine einfache Funktion kann geschrieben werden, um eine Dezimalzahl hin und her zu konvertieren, wenn Sie Daten aus der Datenbank abrufen, sie in ein Dezimalformat konvertieren, alle Berechnungen durchführen und sie dann wieder zurück in ein Zeitformat konvertieren lassen.

Die Verwendung von Unix-Zeitstempeln ist praktisch, wenn Sie Daten berechnen, wahrscheinlich aber nicht so sehr, wenn Sie Zeiten berechnen wollen. Während es scheinen, um einige positive mit diesem, wie sehr leicht Hinzufügen eines Zeitstempels zu einem Zeitstempel, ich habe festgestellt, dass mit alles in Zeitstempel zu Berechnungen zu konvertieren ist lästig und ärgerlich, so würde ich weg von diesem Szenario zu steuern.

Zusammenfassend lässt sich also feststellen:

1. Wenn Sie Daten einfach speichern, aber nicht manipulieren wollen, können Sie Strings eine effektive Methode sein. Sie sind leicht zu lesen und zu überprüfen. Für alles anderes, wählen Sie etwas anderes.
2. Das Rechnen mit Zahlen macht das Rechnen sehr einfach. Konvertieren Sie die Uhrzeit/das Datum in eine Dezimalzahl um, führen Sie alle wichtigen Berechnungen durch und kehren Sie dann zu Echtzeitformat zurück und speichern.
3. Sowohl PHP's Datetime als auch Oracle's Date sind praktisch, und es gibt einige fantastische Funktionen in Oracle und PHP eingebaut, um die Daten zu manipulieren, aber selbst die besten Funktionen können schwieriger sein als das Hinzufügen ein paar Dezimalstellen zu addieren. Ich denke, dass die Speicherung der Daten in der Datenbank in einem Datumsformat zu speichern, ist wahrscheinlich eine sichere Idee - besonders wenn Sie Berechnungen auf der Grundlage der Spalten innerhalb einer Abfrage durchführen wollen. Was Sie innerhalb von PHP mit den Daten machen wollen, wird bestimmen, wie Sie sie verwenden.
4. Option vier würde ich von vornherein ausschließen.

Edit: Ich hatte gerade ein interessantes Gespräch mit einem Freund über Zeittypen. Eine weitere Sache, der man sich bewusst sein sollte, ist, dass zeitbasierte Objekte manchmal mehr Probleme verursachen können als sie lösen. Er befasste sich mit einer Anwendung, in der wir Lieferdaten und -zeiten verfolgen. Die Daten wurden zwar in Datetime-Objekten gespeichert, aber der Haken an der Sache ist, dass die Lieferzeiten für LKWs auf einen bestimmten Tag und ein Lieferfenster festgelegt sind. Eine akzeptable Lieferung ist entweder pünktlich oder bis zu einer Stunde nach der Zeit. Dies führte zu einem gewissen Chaos, als ein Lkw um 23:30 Uhr eintreffen sollte und 45 Minuten später ankam. Obwohl er noch innerhalb des zulässigen Zeitfensters lag, wurde er als am nächsten Tag zugestellt angezeigt. Ein weiteres Problem trat in einem Verteilungszentrum auf, dessen 24-Stunden-Tag um 4:00 Uhr morgens beginnt. Die Einrichtung von Zeiten, die für die Mitarbeiter funktionierten, und die Konsolidierung auf Zahlungen, die sich um ein normales Datum drehten, bereitete ziemliche Kopfschmerzen.