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 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?

[Bernhard Geyer]

Zitat von 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?

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 von mkinzler:

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 von Bernhard Geyer:

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.

[Dejan Vu]

Zitat von Bernhard Geyer:

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.

[Bernhard Geyer]

Zitat von Dejan Vu:

Zitat von Bernhard Geyer:

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 von Dejan Vu:

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
trunc(datefield) z.b.

SQL-Code:

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

Gruß
K-H