SQL Datum ohne Uhrzeit in DB speichern

[Zhen]

Hallo Leute,
ich hab Google bereits bemüht, aber leider nicht die gewünschte Antwort bzw. überhaupt eine Antwort auf DIESE Frage erhalten.

Hoffe daher ihr könnt mir weiterhelfen, da in Sachen Datenbanken ich bislang nicht viel zu tun hatte

Als die Frage ist eigentlich folgende: "Kann man Datumswerte OHNE Uhrzeit in die DB speichern?"
Also wirklich so, dass ich es später beim auslesen nicht nochmals konvertieren, casten oder sonstiges muss (wie in den ganzen Suchergebnissen die ich bislang zu sehen bekam!).

Vor allem aber welchen Datentyp brauch ich dafür, wenn es wirklich möglich ist?

Es handelt sich bei der ganzen Sache um MS SQL Server 2008 Express.


Danke schon mal im Vorraus

 

[Reglohln]

Ohne erneute Umwandlung fällt der Timestamp dann wohl raus.

Wenn das Datum komplett mit Punkten abgespeichert werden soll, dann bleibt wohl nur ein String.

Aber warum speicherst du nicht den timestamp ab und konvertierst dann beim Auslesen mit der Date()-Funktion?

 

[tRITON]

Ja kann man ... 10 Sekunden Google

http://msdn.microsoft.com/de-de/library/vstudio/bb675168.aspx

 

[Zhen]

Naja ich hät eben gerne eine Lösung ohne Konvertierung
Hätte es mir zumindestens gewünscht

Aber danke schon mal für den Tipp

 

[Ruheliebhaber]

Die Frage ist, warum willst Du die Datumsfelder "beschneiden" und was ist so schlimm daran, die Zeit entweder bei der Abfrage oder später bspw. in der Präsentationsschicht zu filtern?

Mit welcher Technologie wertest Du die Datenbank aus? Schreibst Du eine Anwendung in .NET? Wenn die DB nur Mittel zum Zweck ist und nicht im Fokus der Entwicklung steht, würde ich mir mal das ER-Framework ansehen. Dann kannst Du Dich auf Deine Business-Logik konzentrieren und mußt Dich nicht mit dem DBMS rumschlagen.

 

[Ic3HanDs]

Ich würde es auch wenn es nicht benötigt wird erstmal mit Uhrzeit als Timestamp speichern und nachher casten. Wenn du die Daten später doch mal brauchst hast die halt dann direkt.. Und mehr Speicher braucht es ja auch nicht..

 

[Reglohln]

OK - SQL Server 2008 scheint da einiges an Board zu haben.

Aber es wäre ja denkbar, dass man irgendwann doch noch die Uhrzeit braucht und wenn man sie nie mitgespeichert hat, ist einfach verloren. Mit Datum und Zeit könnte man im Nachhinein noch umschwenken. Nur so ein Gedanke.

 

[Zhen]

Spitze. Vielen Dank tRITON.

Da habe ich wohl nach den falschen Begriffen gegoogelt

Ergänzung (25. März 2013)

@all:

Nein bei diesem Feld wird die Uhrzeit niemals gebraucht werden. Auch in Zukunft nicht.
Mein Datensatz enthält dafür aber ein weiteres Feld, dass die Uhrzeit braucht, dieses hab ich auch vom Typ "datetime" deklariert.
Dieses Feld wird nämlich immer aktualisiert wenn der Datensatz bearbeitet wurde.

Das erste Feld brauch ich aber nur um das Datum zu kennen wann der Datensatz angelegt wurde.

Danke nochmals an alle

 

[Ruheliebhaber]

Hm. Ich will Dir nicht reinreden, aber eventuell lohnt es sich, noch einmal 5 Minuten über den DB-Entwurf nachzudenken. Eventuell macht es Sinn, Datum und Uhrzeit relational aufzulösen.

Wenn Du es dennoch so machen willst oder mußt, würde ich sehr genau die Grenzfälle testen. In diesem Fall ist das, wenn die Uhrzeit nahe Mitternacht liegt. Bei 2 Feldern wäre ich mir nicht sicher, daß Mitternacht immer Mitternacht ist, wenn ich 2 Felder und einen selbsterdachten Algorithmus nutze.

 

[Daaron]

Is trotzdem sparsamer und leichter, einfach für alles Timestamps zu nehmen. Integer benötigen weit weniger Platz als andere Datentypen und beim Schreiben der Daten brauchste da nur ein NOW() mitzugeben.

 

[Zhen]

Nun da der Entwurf auch noch nicht zu 100 % endgültig ist, werde ich natürlich eure Ratschläge miteinbeziehen und nochmals drüber gehen

Ich bedanke mich nochmals

 

[Dese]

also ob MS sql server so etwas unterstützt weiß ich nicht.

aber sowohl MySQL als auch Oracle unterstüztun vetrschiedene datum speicherformate, auch das von dem TE gewünschte. es ist ziemlihc gängig. java hat dafür auch extra java.sql.Date, welches nur das datum ohne zeit speichert.

 

[mambokurt]

Nachdem du die komplizierten Antworten durchhast: einfach als Zahl. 20130323 also TTTTMMDD. Damit kannst du dann sogar passend sortieren und größer und kleiner Datümser vergleichen

 

[carom]

Dafür sind konsistenzssichernde Maßnahmen in der DB um ein vielfaches komplizierter und etwaige Datumsfunktionen der DB lassen sich auch nicht nutzen. Die Lösung ist nur auf den ersten Blick günstig.

 

[Daaron]

@mambokurt
So eine Lösung macht spätestens dann Probleme, wenn es um Zeitzonen geht. Timestamps sind immer in GMT, da existiert so ein Problem nicht. Und ein >/< - Vergleich ist mit tstamp ebenfalls ein Witz. Oh, und zu guter letzt muss man da nicht noch extra erklären, in welchem Format die Daten vorliegen.
Ist "11121009" jetzt YYYYMMDD oder YYYYDDMM? Oder sogar MMDDYYYY? DDMMYYYY? Unix Timestamps sind hingegen absolut eindeutig. Sie werden außerdem erst 2038 zu einem Problem, ist noch genug Zeit.

 

[Ruheliebhaber]

@Daaron: Gehen die nur bis 2038? In Langläuferprojekten könnte das schon relevant sein.

 

[carom]

Mit Timestamp bezieht sich Daaron wohl auf die Unixzeit, und bei Systemen, welche diese als 32bit signed integer verwalten, ist dort im Jahr 2038 theoretisch Schluss. Das ist aber logischerweise nicht die Schuld der Unixzeit, sondern der Implementierung. Dort, wo man es schafft, bis 2038 eine 64bit Repräsentation einzubauen, wird auch nichts anbrennen. Wenn du jetzt also ein neues Projekt anfängst, kannst du getrost die Unixzeit verwenden, wenn du diese anderen Timestamp-Formaten vorziehst.

Und die 64bit reichen dann ein paar hundert Milliarden Jahre, da passt ne Menge rein

In der .NET-Welt gibt es als 64-bit Zeitangabe unter anderem so genannte Ticks, die seit dem Jahr 1 (und nicht etwa 1970) gezählt werden. Ein Tick entspricht dabei 100 Nanosekunden. Trotz der 64bit reicht selbst diese extreme Auflösung für etwa 30.000 Jahre.

 

[mambokurt]

@Daaron

Er wollte ein Datum ohne Uhrzeit speichern, voila. Weder ihr noch ich wisst _wozu_ dieses Feld dienen soll, ergo kann auch keiner von uns sagen welche Lösung besser ist. Klar sind Timestamps eindeutig, spätestens wenn du mal mit Sommer/Winterzeit kollidiert bist oder die Differenz zweier Daten ermitteln willst sind Timestamps aber auch ein wenig schizophren. Versteh mich nicht falsch, ich nutze quasi nur Timestamps, aber ich würde nicht sagen dass sie für _jede_ Situation das Mittel der Wahl sind.
Was die Zeitzonen angeht: wenn du die berücksichtigen mußt sicherlich, da wir hier aber ein Datum ohne Zeitangabe speichern: IMHO hinfällig (wobei ISO 8601 auch dafür eine Lösung hat, dadurch wird das ganze aber etwas unansehnlich). Wie gesagt: kommt auf den Zweck an.
Was das Format angeht: klar muss ich dokumentieren dass das ISO 8601 ist, müßte ich aber bei einem Timestamp genauso: '20020312' kann ein Timestamp sein, aber auch alles andere

@carom
Und klar ist die eingebaute Datumsfunktion von Datenbanken super, nur sind die ganzen Datenbankfunktionen spätestens wenn ich mehr als eine Datenbank unterstütze sowieso hinfällig. Wenn ich die Wahl habe dann 4 verschiedene Datenbankfunktionen auf 4 verschiedenen DBMS zu nutzen oder das ganze programmseitig zu lösen mache ich eh letzteres und nehme einen Zeitstempel.

Zu guter Letzt: ich habe _noch nie_ ein Datum als JJJJMMTT in die Db geschoben, aber für gewisse Zwecke kann ich es mir durchaus vorstellen. Ich mußte schon ziemlich oft mit einer Anzahl von Tagen rechnen, und da werden Timestamps ehrlich gesagt zur Krücke. Für Geburtsdaten könnte ich mir das zB vorstellen, so rechnet man relativ einfach ein Alter in Monaten und Tagen aus. Auch für Auswertungen finde ich das ehrlich gesagt einfacher: will ich alle Datensätze zwischen 01. Januar und 25. Februar auswerten, kann ich bei ISO 8601 einfach X >= 20130101 AND X <= 20130225 absetzen, bei Timestamps müßte ich dann erst die letzte Sekunde des 25. Februars ausrechnen, obwohl die Uhrzeit für meine Datensätze völlig egal ist.

Letztendlich wollte ich nur darauf hinweisen dass man es sich nicht immer kompliziert machen muss, unter bestimmten Umständen ist ISO 8601 IMHO absolut legitim, solange alle damit leben können.

 

[Daaron]

Ich mußte schon ziemlich oft mit einer Anzahl von Tagen rechnen, und da werden Timestamps ehrlich gesagt zur Krücke. Für Geburtsdaten könnte ich mir das zB vorstellen, so rechnet man relativ einfach ein Alter in Monaten und Tagen aus.

http://www.php.net/manual/en/datetime.diff.php und so kennst du offensichtlich also noch nicht.

Auch für Auswertungen finde ich das ehrlich gesagt einfacher: will ich alle Datensätze zwischen 01. Januar und 25. Februar auswerten, kann ich bei ISO 8601 einfach X >= 20130101 AND X <= 20130225 absetzen, bei Timestamps müßte ich dann erst die letzte Sekunde des 25. Februars ausrechnen, obwohl die Uhrzeit für meine Datensätze völlig egal ist.

Kinderkram-Aufgabe. 1-2 gut platzierte WHERE-Bedingungen im Query...

 

[mambokurt]

http://www.php.net/manual/en/datetime.diff.php und so kennst du offensichtlich also noch nicht.

Also mache ich per date aus meinem Timestamp einen String den ich dann an diff verfüttere. Genau das meinte ich mit Krücke: klar gehts, aber elegant ist was andres

Kinderkram-Aufgabe. 1-2 gut platzierte WHERE-Bedingungen im Query...

Die ersten 5 Queries ist es Kinderkram, danach nur noch nervig und früher oder später eine Fehlerquelle wenn du mal vergisst die restlichen 23:59:59 abzufangen. Warum mit sowas rumärgern wenn ich doch nur ein Datum brauche und eben keine Uhrzeit? Wie gesagt, ich habe noch nie was anderes als Timestamps benutzt, aber jetzt im Nachhinein fallen mir da einige Stellen ein wo Jahr-Monat-Tag Fehler verhindert oder zumindest Zeit erspart hätte. Man erkauft sich das mit weniger Flexibilität _falls_ man später doch mal eine Uhrzeit dazu braucht, aber wie oft ändert ein Feld in der DB schon so grundlegend seine Anforderungen?