Wie am besten ein Datum und eine Uhrzeit in der DB speichern?

[AlexII]

Hallo,

ich bin kein DB-Spezialist, daher wollte ich fragen wie man am besten ein Datum und eine Uhrzeit in der DB speichern? Als TEXT oder DATETIME Datentyp? Was spricht für TEXT und was für DATETIME? TEXT finde ich flexibler, man kann das Datum und die Uhrzeit im beliebigen Format abspeichern, was für verschiedene Ländereinstellungsstandards gut ist und man kann in dem Feld gut suchen. DATETIME dagegen wandelt das ganze in irgendwelche Zahlenfolge um somit ist die Suche nicht möglich.

Was denkt ihr darüber? Danke!

[Der schöne Günther]

Zitat:

Was spricht für TEXT

Als Datenbank-Laie würde ich sagen: Nichts.

Wenn du es schon als Text speichern willst, dann in einem internationalen Standard wie ISO 8601.

Aber jede Datenbank hat einen Feldtyp für Datum/Zeit, grade das ist doch der Sinn dahinter dass man sich mit den Umwandlungen nicht mehr rumärgern muss und du dir direkt einen

Delphi-Quellcode:

TDateTime

-Wert daraus holen kannst...

[himitsu]

Warum als Text?
Und gut suchen? Nein!

* Man muß es erst konvertieren, dabei kann viel schief gehen (anderes Datumsformat und schon knallt es z.B. DE <> EN)
* es braucht mehr Platz
* man kann damit nicht rechnen (Datum + 4 Tage)
* es lässt sich blöde sortieren
* und filtern geht sowieso nicht (von-bis)
* wenn, dann dauert filtern/sortieren auch noch länger


Speicherst du Zahlen und vorallem Fließkommazahlen auch als Text?

[mkinzler]

Werte immer im entsprechenden Typen speichern!
Bei der Speicherung als Text handelst Du dir nur ein enormes Fehlerpotential ein.
Die Speicherung als DateTime hat den Vorteil, dass diese unabhängig vom Datumsformat ist ( Sprache, Kurz-/Langformat, ...)

[baumina]

Man hätte DateTime nicht erfunden, wenn es nicht sinnvoller wäre als Text.

- frei formatierbar in der Darstellung
- Zeitzonen unabhängig
- sortierbar
- man kann damit rechnen

Das sind so auf die Schnelle Vorteile, die mir dazu einfallen.

[AlexII]

Ok... dann lässt sich wohl auch die Suche in dem DateTime Feld realisieren, muss nur rausfinden wie. ))

Danke Euch!

[mkinzler]

Was willst Du darin suchen? Du kannst anhand des Wertes Suchen/Filtern (between usw.)

[AlexII]

Zitat:

Zitat von mkinzler (Beitrag 1280492)

Was willst Du darin suchen? Du kannst anhand des Wertes Suchen/Filtern (between usw.)

Habe mich falsch ausgedruckt, selectieren möchte ich, z.B. alle Einträge von 15.11.2014 bis 20.11.2014 ))

[divBy0]

Aus der SQLite Dokumentation:

Zitat:

1.2 Date and Time Datatype

SQLite does not have a storage class set aside for storing dates and/or times. Instead, the built-in Date And Time Functions of SQLite are capable of storing dates and times as TEXT, REAL, or INTEGER values:

TEXT as ISO8601 strings ("YYYY-MM-DD HH:MM:SS.SSS").
REAL as Julian day numbers, the number of days since noon in Greenwich on November 24, 4714 B.C. according to the proleptic Gregorian calendar.
INTEGER as Unix Time, the number of seconds since 1970-01-01 00:00:00 UTC.

Applications can chose to store dates and times in any of these formats and freely convert between formats using the built-in date and time functions.

[Luckie]

Was spricht gegen eine Timestamp? Ganz ungünstig ist es als vorformatiertes Format abspeichern. dann musst du es jedes mal auseinander nehmen und wieder zusammensetzen, wenn es anders dargestellt werden soll. Fängt schon damit an, wenn du nur das Jahr brauchst. Für Timestamps gibt es fertige Funktionen bzw. man schreibt sie sich einmal und fertig. Die sonstigen Vorteile wurden ja schon genannt.

[AlexII]

Zitat:

Zitat von divBy0 (Beitrag 1280494)

Aus der SQLite Dokumentation:

Zitat:

1.2 Date and Time Datatype

SQLite does not have a storage class set aside for storing dates and/or times. Instead, the built-in Date And Time Functions of SQLite are capable of storing dates and times as TEXT, REAL, or INTEGER values:

TEXT as ISO8601 strings ("YYYY-MM-DD HH:MM:SS.SSS").
REAL as Julian day numbers, the number of days since noon in Greenwich on November 24, 4714 B.C. according to the proleptic Gregorian calendar.
INTEGER as Unix Time, the number of seconds since 1970-01-01 00:00:00 UTC.

Applications can chose to store dates and times in any of these formats and freely convert between formats using the built-in date and time functions.

Das hat auch meine Frage ausgelöst. Aber weiter unten auf der Seite ist in der Tabelle DateTime vorhanden, SQLite akzeptiert das auch, also habe ich DateTime genommen.

[AlexII]

Zitat:

Zitat von Luckie (Beitrag 1280495)

Was spricht gegen eine Timestamp? Ganz ungünstig ist es als vorformatiertes Format abspeichern. dann musst du es jedes mal auseinander nehmen und wieder zusammensetzen, wenn es anders dargestellt werden soll. Fängt schon damit an, wenn du nur das Jahr brauchst. Für Timestamps gibt es fertige Funktionen bzw. man schreibt sie sich einmal und fertig. Die sonstigen Vorteile wurden ja schon genannt.

Hm... was genau ist hier ungünstig? Text oder DateTime? :gruebel:

[mkinzler]

Text!

[AlexII]

Zitat:

Zitat von mkinzler (Beitrag 1280499)

Text!

Ok, verstehe :thumb:

[Bernhard Geyer]

Zitat:

Zitat von himitsu (Beitrag 1280485)

Warum als Text?
Und gut suchen? Nein!

* Man muß es erst konvertieren, dabei kann viel schief gehen (anderes Datumsformat und schon knallt es z.B. DE <> EN)
* es braucht mehr Platz
* man kann damit nicht rechnen (Datum + 4 Tage)
* es lässt sich blöde sortieren
* und filtern geht sowieso nicht (von-bis)
* wenn, dann dauert filtern/sortieren auch noch länger


Speicherst du Zahlen und vorallem Fließkommazahlen auch als Text?

Wenn man es nach ISO 8601 speichert gelten viel der Nachteile nicht.
Hier würde nur

* Platz
* Langsamer

übrig bleiben.
Alle anderen Punkte (Filtern/Teile/...) lässt sich prima mit dem ISO-Format machen.
Und wenn man x-DB-Systeme unterstützten will braucht man sich nicht mit den Unterschiedlichen Funktionen an dieser Stelle herumärgern.

Alle anderen (

[mkinzler]

Da er Text als flexibler gehalten hat, hat er wohl an kein standardisiertes Textformat gedacht.

[Bernhard Geyer]

Zitat:

Zitat von mkinzler (Beitrag 1280504)

Da er Text als flexibler gehalten hat, hat er wohl an kein standardisiertes Textformat gedacht.

Flexilber im Sinne von "Alle 2 Wochen Mittwoch um 12:00" wäre das ISO-Format schon.
Flexilber im Sinne von "Ich speicher jetzt nach US-Format" würde ich keinesfalls machen.

[jobo]

Zitat:

Zitat von Bernhard Geyer (Beitrag 1280506)

Flexilber im Sinne von "Alle 2 Wochen Mittwoch um 12:00" wäre das ISO-Format schon.
Flexilber im Sinne von "Ich speicher jetzt nach US-Format" würde ich keinesfalls machen.

Das ISO Format definiert auch Intervalle? Oder vielleicht doch nur maximal Zeitspannen?
Ich frag mich aber eher, ob es wirklich Sinn macht im Zusammenhang mit der Frage (..in der DB..) Text zu empfehlen.
Ich wollte nie Reports oder Abfragen dafür schreiben.

Im Rahmen einer DB-losen Webseite/Anwendung macht es vielleicht schon mehr Sinn. Aber da hab ich kaum Erfahrung.

[himitsu]

Kommt drauf an, welche ISO-Norm man hier anwendet. :angel:

[jobo]

Zitat:

Zitat von himitsu (Beitrag 1280542)

Kommt drauf an, welche ISO-Norm man hier anwendet. :angel:

Ich dachte wir hätten uns demokratisch auf 8601 geeinigt
;)

[AlexII]

Zitat:

Zitat von jobo (Beitrag 1280543)

Zitat:

Zitat von himitsu (Beitrag 1280542)

Kommt drauf an, welche ISO-Norm man hier anwendet. :angel:

Ich dachte wir hätten uns demokratisch auf 8601 geeinigt
;)

Man muss sich für das richtige! entscheiden und nicht für das der Masse. Die Mehrheit irrt sich oft. :wink: Aber ich diesem Fall ist alles ok! :-D

[Dejan Vu]

Zitat:

Zitat von Bernhard Geyer (Beitrag 1280502)

Alle anderen Punkte (Filtern/Teile/...) lässt sich prima mit dem ISO-Format machen.

Wie genau würde ein SELECT für 'zwischen 10:00' und '13:00' aussehen? Also, das es 'prima' ist? Ich würde -allgemein gesehen- eher überlegen, welche Abfragen zu erwarten sind. Es wäre nämlich auch denkbar, Datum und Uhrzeit getrennt abzulegen. Dies ist sinnvoll, wenn ich immer nur ganze Tage betrachten will (auch als Zeitraum) und vielleicht separat noch die Uhrzeit (Schichtbetrieb, Arbeitszeit etc.) Weiterhin bietet das reine Datum noch die Möglichkeit, die Tabelle mit einer date dimension table zu verknüpfen, was komplexeren Auswertungen Tür und Tor öffnet.

Platz spielt im Jahr 2014 und angesichts von GB-Telefonen und TB-Festplatten keine primäre Rolle mehr: Klar, zu verschwenderisch sollte man damit nicht umgehen, aber ob ich für ein Datum 4, 6, 8 oder wasweißich 24 Bytes belege, ist -zumal wir von SQLite reden- nicht weltherrschaftsentscheidend.

[Phoenix]

Zitat:

Zitat von AlexII (Beitrag 1280490)

Ok... dann lässt sich wohl auch die Suche in dem DateTime Feld realisieren, muss nur rausfinden wie. ))

Ist relativ einfach:

Code:

SELECT Col1, Col1
FROM MyTable
WHERE DateField >= '2014-11-21 06:00';

-- oder

SELECT Col1, Col1
FROM MyTable
WHERE DateField BETWEEN '2014-11-01 06:00' AND '2014-11-05 18:00';

Eine Sache solltest Du Dir vorher noch überlegen: Könntest Du, möglicherweise, unter irgendwelchen Umständen, vielleicht, mal auf die Idee kommen, zum einen unterschiedliche Zeitzonen zu bearbeiten? Oder musst Du die Einträge in der doppelten Stunde bei einer Zeitumstellung auf Winterzeit (also zwischen 2 und 3 Uhr an einem Sonntag) in die richtige Reihenfolge bringen können? Also willst Du bei zwei Einträgen um jeweils 02:15 Uhr wissen, welches der beiden 02:15 vor oder nach der Zeitumstellung war?

Falls Du eines der beiden mit Ja beantworten kannst, dann solltest Du alle Zeiten vor der Ablage in der Datenbank in UTC konvertieren. Dann musst Du zwar die Daten vor der Anzeige immer wieder in lokale Zeit umrechnen, aber dafür gibt es in den DateUtils ein paar passende Funktionen, die das recht einfach machen. Der Vorteil ist halt, dass Du immer genau weisst, was da in der DB steht.

[Bernhard Geyer]

Zitat:

Zitat von Dejan Vu (Beitrag 1280558)

Zitat:

Zitat von Bernhard Geyer (Beitrag 1280502)

Alle anderen Punkte (Filtern/Teile/...) lässt sich prima mit dem ISO-Format machen.

Wie genau würde ein SELECT für 'zwischen 10:00' und '13:00' aussehen? Also, das es 'prima' ist?

Einträge sind in der Art: yyyy-mm-dd hh:nn:ss

Pseudo-SQL (Mit Delphi-Funktionen):

Code:

select * from mytable where Copy(myFeld, 12, 5) >= '10:00' and Copy(myFeld, 12, 5) <= '12:59'

[p80286]

Zitat:

Zitat von Dejan Vu (Beitrag 1280558)

Dies ist sinnvoll, wenn ich immer nur ganze Tage betrachten will (auch als Zeitraum) und vielleicht separat noch die Uhrzeit (Schichtbetrieb, Arbeitszeit etc.)

wenn Du nur das Datum benötigst, dann arbete mit

SQL-Code:

trunc(datefield)

z.b.

SQL-Code:

select 'Es ist Weihnachten'
from dual
where trunc(sysdate)=to_date('20141224','YYYYMMDD')

Gruß
K-H