DateTime2 vs. DateTime in SQL Server

Question

Welche?

• datetime
• datetime2

es le site Empfohlene Methode zum Speichern von Datum und Uhrzeit in SQL Server 2008+?

Ich bin mir der Unterschiede in der Genauigkeit (und dem Speicherplatz) bewusst, aber ignoriere diese für den Moment, gibt es ein Best-Practice-Dokument darüber, wann was zu verwenden ist, oder sollten wir vielleicht einfach datetime2 nur?

Answer 1

Hier ein Beispiel, das Ihnen die Unterschiede in der Speichergröße (Bytes) und der Genauigkeit zwischen smalldatetime, datetime, datetime2(0) und datetime2(7) zeigt:

DECLARE @temp TABLE (
    sdt smalldatetime,
    dt datetime,
    dt20 datetime2(0),
    dt27 datetime2(7)
)

INSERT @temp
SELECT getdate(),getdate(),getdate(),getdate()

SELECT sdt,DATALENGTH(sdt) as sdt_bytes,
    dt,DATALENGTH(dt) as dt_bytes,
    dt20,DATALENGTH(dt20) as dt20_bytes,
    dt27, DATALENGTH(dt27) as dt27_bytes FROM @temp

die zurückgibt

sdt                  sdt_bytes  dt                       dt_bytes  dt20                 dt20_bytes  dt27                         dt27_bytes
-------------------  ---------  -----------------------  --------  -------------------  ----------  ---------------------------  ----------
2015-09-11 11:26:00  4          2015-09-11 11:25:42.417  8         2015-09-11 11:25:42  6           2015-09-11 11:25:42.4170000  8

Wenn ich also Informationen sekundengenau - aber nicht auf die Millisekunde genau - speichern möchte, kann ich jeweils 2 Byte einsparen, wenn ich datetime2(0) anstelle von datetime oder datetime2(7) verwende.

Answer 2

DateTime2 richtet großen Schaden an, wenn Sie als Access-Entwickler versuchen, Now() in das betreffende Feld zu schreiben. Ich habe gerade eine Access -> SQL 2008 R2 Migration durchgeführt und alle Datetime-Felder als DateTime2 eingegeben. Das Anhängen eines Datensatzes mit Now() als Wert ist fehlgeschlagen. Am 1/1/2012 2:53:04 PM war es in Ordnung, aber nicht am 1/10/2012 2:53:04 PM.

Ein einziges Mal machte der Charakter den Unterschied. Ich hoffe, es hilft jemandem.

Answer 3

Alte Frage... Aber ich möchte etwas hinzufügen, was hier noch niemand gesagt hat... (Anmerkung: Dies ist meine eigene Beobachtung, also fragen Sie nicht nach einer Referenz)

Datetime2 ist schneller, wenn es in Filterkriterien verwendet wird.

TLDR:

In SQL 2016 hatte ich eine Tabelle mit hunderttausend Zeilen und einer Datetime-Spalte ENTRY_TIME, weil sie die genaue Zeit bis auf Sekunden genau speichern musste. Beim Ausführen einer komplexen Abfrage mit vielen Verknüpfungen und einer Unterabfrage, wenn ich die Where-Klausel als:

WHERE ENTRY_TIME >= '2017-01-01 00:00:00' AND ENTRY_TIME < '2018-01-01 00:00:00'

Die Abfrage war anfangs in Ordnung, wenn es Hunderte von Zeilen gab, aber als die Anzahl der Zeilen zunahm, begann die Abfrage diesen Fehler zu geben:

Execution Timeout Expired. The timeout period elapsed prior
to completion of the operation or the server is not responding.

Ich habe die Where-Klausel entfernt, und unerwarteterweise wurde die Abfrage in 1 Sekunde ausgeführt, obwohl jetzt ALLE Zeilen für alle Daten abgerufen wurden. Ich führte die innere Abfrage mit der Where-Klausel aus, und sie dauerte 85 Sekunden, und ohne Where-Klausel dauerte sie 0,01 Sekunden.

Ich bin hier auf viele Threads zu diesem Thema gestoßen, da Leistung der Datumsfilterung

Ich habe die Abfrage ein wenig optimiert. Aber die wirkliche Geschwindigkeit, die ich bekam, war durch die Änderung der datetime Spalte zu datetime2.

Jetzt dauert dieselbe Abfrage, die zuvor eine Zeitüberschreitung verursachte, weniger als eine Sekunde.

Prost

Answer 4

Interpretation von Datumsstrings in datetime y datetime2 kann auch anders sein, wenn man nicht-US DATEFORMAT Einstellungen. z.B.

set dateformat dmy
declare @d datetime, @d2 datetime2
select @d = '2013-06-05', @d2 = '2013-06-05'
select @d, @d2

Dies ergibt 2013-05-06 (d.h. am 6. Mai) für datetime そして 2013-06-05 (d.h. am 5. Juni) für datetime2 . Doch mit dateformat eingestellt auf mdy beide @d y @d2 return 2013-06-05 .

El datetime Verhalten scheint im Widerspruch zu den MSDN-Dokumentation von SET DATEFORMAT die besagt: Einige Zeichenkettenformate, z. B. ISO 8601, werden unabhängig von der DATEFORMAT-Einstellung interpretiert . Offensichtlich nicht wahr!

Bis ich davon gebissen wurde, hatte ich immer gedacht, dass yyyy-mm-dd Die Datumsangaben werden unabhängig von den Sprach- und Gebietsschemaeinstellungen richtig behandelt.

Answer 5

Während es zu einer erhöhten Präzision con datetime2 einige Clients unterstützen nicht Datum , Zeit o datetime2 und zwingt Sie, in ein String-Literal zu konvertieren. Speziell Microsoft erwähnt "down level" ODBC, OLE DB, JDBC und SqlClient Probleme mit diesen Datentypen und hat eine Karte die zeigen, wie jeder den Typ abbilden kann.

Wenn der Wert Kompatibilität über Präzision, verwenden Sie datetime