In Datenbanken ist ein Datum ein ganz wichtiger Punkt der häufig verwendet werden muss. Dementsprechend gibt es auch viele Möglichkeiten ein Datum ein einer Datenbank zu speichern. Leider sieht man auch immer wieder, dass ein Datum als String abgespeichert wird. Ich kenne keinen Fall in dem das sinnvoll wäre. Man verbaut sich damit alle Chancen die ein als Datum typisiertes Feld bietet. Allein schon die Probleme wenn das Datum dann aus verschiedenen Regionen gespeichert wird, in denen vielleicht die Reihenfolge anders ist. Man kann dann nicht mehr sicher sagen ob 2017-09-10 der 10. September 2017 oder der 9. Oktober 2017 ist. Ein Datum sollte immer typisiert gespeichert werden. Aber auch hier bietet der SQL Server einige Möglichkeiten an. In älteren Versionen des SQL Servers war man da noch begrenzt in den Möglichkeiten. Inzwischen kann man aber genau das Format wählen, dass zu dem Datumstyp passt den man speichern will. Also Datum versteht man hierbei nicht zwingend nur einen Tag sondern auch die passende Uhrzeit, also einen Zeitpunkt.

Beim Datenbankdesign gilt immer der Grundsatz, den Typen so klein wie möglich wählen. Es gilt also sich vorher Gedanken zu machen welche Art von Datum man speichern will.

Zeitpunkt speichern

Will man einen genauen Zeitpunkt speichern bieten sich die Formate SMALLDATETIME, DATETIME, DATETIME2 oder DATETIMEOFFSET an. DATETIME bietet eine Speicherung mit einer Genauigkeit von Millisekunden an. Bei DATETIME2 können auch Nanosekunden gespeichert werden. SMALLDATETIME hingegen bietet nur eine Genauikeit von Sekunden.  DATETIMEOFFSET bietet zusätzlich die Möglichkeit auch eine Zeitzone mitzuspeichern. Allgemein ist bei der Speicherung von Datum das Problem der Zeitzonen immer zu beachten. Wenn davon ausgegangen wird, dass aus verschiedenen Zeitzonen aus Datum gespeichert wird muss man dies bereits beim Design der Datenbankstrukturen berücksichtigen. DATETIMEOFFSET ist eine Möglichkeit, alternativ kann sonst auch Grundsätzlich mit der Serverzeit gespeichert werden. Die Unterschiede der einzelnen Formate liegen nicht nur in der Genauigkeit sondern auch in der Menge an Speicherplatz die sie benötigen. Je Höher die Genauigkeit, desto höher der Speicherbedarf. SMALLDATETIME kommt mit nur 4 Bytes aus wo hingegen DATETIMEOFFSET 8-10 Bytes Speicherplatz benötigt. Je nach Menge der gespeicherten Datensätze ist dies schon ein deutlicher Unterschied in der letztendlichen Datenbankgröße.

Datum oder Zeit speichern

In einigen Fällen reicht es auch nur ein Datum oder eine Zeit zu speichern. Hierfür gibt es auch geeignete Formate. DATE und TIME benötigen nur 3-5 Byte Speicherplatz und sind somit perfekt geeignet wenn nur der Tag oder die Zeit benötigt wird.

Timestamp

Aus anderen Datenbanksystemen ist der Timestamp bekannt. Gerade im Unix/Linux Umfeld wird dieser häufig verwendet. Der Timestamp ist dann meistens ein Counter in Sekunden seit einem bestimmten Zeitpunkt. Der SQL Server kennt diesen Datentyp nicht nativ. Man kann es natürlich über einen INT oder BIGINT lösen.

Welchen Datentyp wähle ich jetzt?

Erste Frage muss immer sein, welche Informationen muss ich speichern. Also Dinge wie:

• Welche Genauigkeit brauche ich?
• Muss ich die Zeit mitspeichern?
• Brauche ich Zeitzonen in meinem Datum?
• Reicht mit UTC als Zeit?
• Woher kommt meine Zeitinformation?

Die ersten beiden Fragen kann jeder nur an Hand seiner Datenbasis bzw. der Daten die erwartet werden bestimmen. Hier nur der immer gültige Hinweis. Einmal nicht gespeicherte Informationen bekomme ich nicht wieder. Wenn ich nicht sicher sagen kann, dass ich bspw. die Zeit nicht doch später mal benötige sollte ich sie lieber mitspeichern.
Zu den Fragen Zeitzonen ja nein kann man geteilter Meinung sein. Eigentlich ist weit verbreitet, dass man Zeit immer in UTC speichert und dann auf die entsprechende Zeit umrechnet. Oft muss man aber auch wissen aus welcher Zeitzone heraus gespeichert wurde, dann kommt man nicht darum herum die Zeitzone mitzuspeichern und DATETIMEOFFSET zu verwenden.

Beachtet man einen dieser Punkte nicht wird es später sehr schwer das wieder zu korrigieren. Alleine Datum von „irgendeiner lokalen Zeit“ zu UTC ist nicht fehlerfrei möglich, da ich normalerweise nicht nachvollziehen kann aus welcher Zeitzone heraus die Daten gespeichert wurden. Zusätzlich muss ich auch Sommer- und Winterzeit beachten. Dafür muss dann oft auf Tools außerhalb des SQL Servers zurückgegriffen werden.

Warum die Frage woher die Zeitinformationen kommen? Stell dir mal vor, du hast an deinem Rechner nicht die automatische Synchronisation der Uhr eingestellt und hast die Uhr verstellt. Soll dann eine Transaktion die von deinem Rechner aus gemacht wurde mit der lokalen Zeit oder der Zeit des Servers eingetragen werden. Je nach Situation könnte man sich dann z.b. einen Vorteil verschaffen wenn man seine Zeit am Rechner umstellt und auf einmal vor anderen in Rankings landen. Es hat bestimmt jeder schon mal von jemandem gehört der sowas bei Spielen anwendet 😉 Meine Empfehlung ist eigentlich die Serverzeit zu nehmen. Aber was passiert dann mit den Zeitzonen? Das muss jeder für seine Anwendung klären.

Ihr seht, Zeit und SQL Server sind einige Punkte die man beachten muss. Noch mehr als bei anderen Dateitypen gilt es vorher festzulegen was man wo wie speichern will, mit einfach nur Datum speichern ist es nicht getan.