SQL Datum ohne Uhrzeit in DB speichern

[carom]

Wenn man ein Datum einfach als Datum abspeichern würde und nicht als Ganzzahl, dann müsste man weder etwas dokumentieren, noch sich um die Integrität kümmern. Wenn einem die Datenbank schon Typsicherheit bietet, dann sollte man das auch Nutzen.

Bei einem Unix-Timestamp ist das was anderes, denn dieser repräsentiert kein Datum, sondern per Definition eine Anzahl an Sekunden. Dass man daraus ein Datum ableiten kann, ist eine andere Geschichte. Ein Unix-Timestamp hat keine Struktur, nur einen Wert.

Das sieht bei ISO 8601 anders aus, denn dort ist die Struktur das wichtigste, und dafür ist eine Ganzzahl nicht gedacht. Gerade gegen die wichtigsten beiden Eigenschaften eines ISO 8601 Timestamps, nämlich der festen Länge und dem Auffüllen mit Nullen bei Nichterreichen dieser Länge, ist eine Ganzzahl geradezu allergisch.

Verstehe mich nicht falsch, ich bin mit ISO 8601 völlig einverstanden, aber durch eine Ganzzahl kann man das Format nicht abbilden, es klemmt hinten und vorne. Eine Zahl hat einfach keine Struktur, sondern repräsentiert nur einen Wert, da lässt sich nicht dran rütteln. Ein Unix-Timestamp meint immer exakt die selbe Sekunde, egal ob man ihn als Dezimal-, Oktal- oder Hexadezimalzahl betrachtet, bei ISO 8601 als Ganzzahl würde das nicht gelten.

Und gerade deswegen verstehe ich auch nicht, warum du anführst, dass man damit besonders gut rechnen könnte. Ich kann mir eigentlich nichts komplizierteres vorstellen, als damit zu rechnen.

edit: Wie rechnest du überhaupt damit, könntest du bitte ein paar Beispielrechnungen anführen?

 

[mambokurt]

Rechnen ist zu viel gesagt, die Reihenfolge der Darstellung hat halt den Vorteil, dass du größer/kleiner verwenden kannst und wenn du einen Stempel vom anderen abziehst bekommst du die Differenz in Jahren,Monaten, Tagen. Damit kann man zB sehr schön ein Alter ausrechnen. zB alle Kinder älter als 14: SELECT * from bla where (20130326 - birthdate) >= 00140000 (führende Nullen nur der Klarheit halber). Ich postuliere hier auch nicht dass das das Nonplusultra ist, einfach nur dass es ginge und verhältnismäßig einfach ist. Ob es überhaupt in Frage kommt hängt vom Problem und wahrscheinlich auch Geschmack ab.

Was führende Nullen angeht gebe ich dir recht, auf der anderen Seite gehört das wohl eher zum Bereinigen des Userinputs, muss ja sowieso sein. Ansonsten wäre das nur bei Jahreszahlen vor 1000 interessant, wird in den meisten Daten eher nicht auftreten.

Und zu Datum als Datum: wenn das jedes DBMS gleich machen würde würden wir hier nicht diskutieren, aber wenn man für mehr als eine Datenbank plant bleibt letztendlich fast nur der Timestamp, oder du baust halt für jedes DBMS eigene Statements zusammen.

Letztendlich hat alles seine Vor- und Nachteile und wird eher von der Umgebung und der Aufgabe diktiert als dass man groß die Wahl hätte was man nimmt.

 

[AlbertLast]

Jedes rdbms kann Date, DateTime und Timestamp, viele können auch timestamp mit zeitzone.

Date und time getrennt zu speichern, kann es gute Gründe geben:
Gerade wenn man where Bedingungen nur auf die Uhrzeit macht, hier versagen indexe auf DateTime spalten.

Unix_timestamp und ähnliche Konstruktionen (YYYYMMDD) gehören aus meiner Sicht nicht in die DB, das sind irgendwelche Krücken von Programmierer die dann Datum / Uhrzeit Berechnung auf die Applikation auslagern wollen.

 

[Zhen]

Naja ich brauch wirklich nur Tag, Monat und Jahr in diesem Fall.
Soll später dazu dienen um festzustellen wann etwas aktiviert wurde und wie lange es noch läuft bzw. Garantie hat (bis wann).

Ich glaub da reicht ein einfaches Date aus. Damit kann man auch dann Tage, Monate und Jahre berechnen oder? Wobei es mir vorrangig auf Jahre und dann noch auf Monate ankommt (Tage brauche ich eig. dann eh nicht - zumindestens zum Rechnen nicht).