DateTime2 vs DateTime in SQL Server

Quale:

• datetime
• datetime2

è il modo consigliato per memorizzare data e ora in SQL Server 2008+?

Sono consapevole delle differenze di precisione (e probabilmente dello spazio di archiviazione), ma ignorandole per ora, esiste un documento di best practice su quando usare cosa, o forse dovremmo usare datetime2solo?

La documentazione MSDN per datetime consiglia di utilizzare datetime2 . Ecco la loro raccomandazione:

Utilizzare i time, date, datetime2e datetimeoffsettipi di dati per un nuovo lavoro. Questi tipi si allineano con lo standard SQL. Sono più portatili. time, datetime2E datetimeoffset fornire più secondi precisione. datetimeoffsetfornisce il supporto del fuso orario per le applicazioni distribuite a livello globale.

datetime2 ha un intervallo di date più ampio, una precisione frazionaria predefinita più ampia e una precisione specificata dall'utente facoltativa. Inoltre, a seconda della precisione specificata dall'utente, potrebbe utilizzare meno spazio di archiviazione.

DATETIME2ha un intervallo di date compreso tra " DATETIME0001/01/01 " e " 9999/12/31 ", mentre il tipo supporta solo l'anno 1753-9999.

Inoltre, se necessario, DATETIME2può essere più preciso in termini di tempo; DATETIME è limitato a 3 1/3 millisecondi, mentre DATETIME2può essere preciso fino a 100 ns.

Entrambi i tipi eseguono il mapping System.DateTimein .NET - nessuna differenza lì.

Se hai la scelta, consiglierei di usarlo DATETIME2ogni volta che è possibile. Non vedo alcun vantaggio utilizzando DATETIME(tranne per la compatibilità con le versioni precedenti) - avrai meno problemi (con date che sono fuori portata e seccature del genere).

Inoltre: se hai solo bisogno della data (senza la parte del tempo), usa DATA - è altrettanto buono DATETIME2e ti fa risparmiare spazio! :-) Lo stesso vale solo per il tempo - usa TIME. Ecco a cosa servono questi tipi!

datetime2 vince in molti aspetti tranne (Compatibilità vecchie app)

1. più ampio intervallo di valori
2. migliore precisione
3. spazio di archiviazione più piccolo (se viene specificata la precisione specificata dall'utente opzionale)

si prega di notare i seguenti punti

• Sintassi
  • datetime2 [(precisione frazionaria dei secondi => Cerca sotto le dimensioni di archiviazione)]
• Precisione, scala
  • Da 0 a 7 cifre, con una precisione di 100 ns.
  • La precisione predefinita è di 7 cifre.
• Dimensione di archiviazione
  • 6 byte per precisione inferiore a 3;
  • 7 byte per precisione 3 e 4.
  • Tutte le altre precisione richiedono 8 byte .
• DateTime2 (3) hanno lo stesso numero di cifre di DateTime ma utilizza 7 byte di memoria anziché 8 byte ( SQLHINTS- DateTime Vs DateTime2 )
• Ulteriori informazioni su datetime2 (articolo MSDN Transact-SQL)

fonte immagine: Kit di training autonomo MCTS (esame 70-432): Microsoft® SQL Server® 2008 - Implementazione e manutenzione Capitolo 3: Tabelle -> Lezione 1: Creazione di tabelle -> pagina 66

Concordo con @marc_s e @Adam_Poward - DateTime2 è il metodo preferito per andare avanti. Ha una gamma più ampia di date, maggiore precisione e utilizza una memoria uguale o inferiore (a seconda della precisione).

Una cosa che la discussione ha mancato, però ...
@Marc_s afferma: Both types map to System.DateTime in .NET - no difference there. Questo è corretto, tuttavia, l'inverso non è vero ... ed è importante quando si eseguono ricerche nell'intervallo di date (ad es. "Trovami tutti i record modificati il ​​5/5/2010").

La versione di .NET Datetimeha una gamma e una precisione simili a DateTime2. Quando si associa una .net Datetimeal vecchio SQL, si verificaDateTime un arrotondamento implicito . Il vecchio SQL ha DateTimeuna precisione di 3 millisecondi. Ciò significa che 11:59:59.997è il più vicino possibile alla fine della giornata. Qualsiasi cosa superiore viene arrotondata per eccesso al giorno seguente.

Prova questo :

declare @d1 datetime   = '5/5/2010 23:59:59.999'
declare @d2 datetime2  = '5/5/2010 23:59:59.999'
declare @d3 datetime   = '5/5/2010 23:59:59.997'
select @d1 as 'IAmMay6BecauseOfRounding', @d2 'May5', @d3 'StillMay5Because2msEarlier'

Evitare questo arrotondamento implicito è un motivo significativo per passare a DateTime2. L'arrotondamento implicito delle date provoca chiaramente confusione:

• Strano comportamento datetime in SQL Server
• http://bytes.com/topic/sql-server/answers/578416-weird-millisecond-part-datetime-data-sql-server-2000-a
• SQL Server 2008 e millisecondi
• http://improve.dk/archive/2011/06/16/getting-bit-by-datetime-rounding-or-why-235959-999-ltgt.aspx
• http://milesquaretech.com/Blog/post/2011/09/12/DateTime-vs-DateTime2-SQL-is-Rounding-My-999-Milliseconds!.aspx

Quasi tutte le risposte e i commenti sono stati pesanti sui pro e leggeri sui contro. Ecco un riassunto di tutti i pro e contro finora, oltre ad alcuni contro cruciali (nel n. 2 di seguito) che ho visto menzionato solo una volta o per niente.

1. PROFESSIONISTI:

1.1. Più conforme ISO (ISO 8601) (anche se non so come questo entri in gioco nella pratica).

1.2. Più intervallo (dall'1 / 1/0001 al 31/12/9999 rispetto al 1/1 / 1753-12 / 31/9999) (sebbene l'intervallo supplementare, tutto prima dell'anno 1753, probabilmente non verrà utilizzato tranne che per es., in app storiche, astronomiche, geologiche, ecc.).

1.3. Corrisponde esattamente all'intervallo dell'intervallo di DateTimetipi di .NET (sebbene entrambi convertano avanti e indietro senza codifica speciale se i valori rientrano nell'intervallo e nella precisione del tipo di destinazione, ad eccezione di Con # 2.1, altrimenti si verificheranno errori / arrotondamenti).

1.4. Maggiore precisione (100 nanosecondi aka 0.000.000,1 sec. Vs. 3,33 millisecondi aka 0,003,33 sec.) (Anche se la precisione extra probabilmente non verrà utilizzata se non per es., In app di ingegneria / scientifiche).

1.5. Se configurato per una precisione simile (come in 1 millisec non "uguale" (come in 3,33 millisec) come affermato da Iman Abidi) DateTime, usa meno spazio (7 contro 8 byte), ma ovviamente perdi vantaggio di precisione che è probabilmente uno dei due (l'altro è il range) più propagandato sebbene probabilmente benefici non necessari).

2. CONS:

2.1. Quando si passa un parametro a un .NET SqlCommand, è necessario specificare System.Data.SqlDbType.DateTime2se si sta passando un valore al di fuori DateTimedell'intervallo e / o della precisione di SQL Server , perché per impostazione predefinita è System.Data.SqlDbType.DateTime.

2.2. Non può essere implicitamente / facilmente convertito in un valore numerico in virgola mobile (numero di giorni dalla data-ora minima) per eseguire le seguenti operazioni su / con esso nelle espressioni di SQL Server utilizzando valori numerici e operatori:

2.2.1. aggiungere o sottrarre # di giorni o giorni parziali. Nota: l'utilizzo della DateAddfunzione come soluzione alternativa non è banale quando è necessario considerare più se non tutte le parti della data-ora.

2.2.2. prendere la differenza tra due date-orari ai fini del calcolo dell '"età". Nota: non è possibile semplicemente utilizzare la DateDifffunzione di SQL Server , perché non viene calcolata agecome la maggior parte delle persone si aspetterebbe che se le due date-date attraversano un limite di data / ora del calendario / orologio delle unità specificate se anche per una piccola frazione di quell'unità, restituirà la differenza come 1 di quell'unità rispetto a 0. Ad esempio, l' DateDiffin Day's di due date-time a solo 1 millisecondo di distanza restituirà 1 vs. 0 (giorni) se tali time-date sono in diversi giorni di calendario (ad es. "1999-12-31 23: 59: 59.9999999" e "2000-01-01 00: 00: 00.0000000"). La stessa differenza di 1 millisecondo di date-orari se spostata in modo che non attraversino un giorno di calendario, restituirà un "DateDiff" in Day's di 0 (giorni).

2.2.3. prendere la Avgdata-ora (in una query aggregata) semplicemente convertendo prima in "Float" e poi di nuovo in DateTime.

NOTA: per convertire DateTime2in un numero, devi fare qualcosa come la seguente formula che presuppone che i tuoi valori non siano inferiori all'anno 1970 (il che significa che stai perdendo tutto l'intervallo extra più altri 217 anni. Nota: potresti non essere in grado di regolare semplicemente la formula per consentire un intervallo extra perché potresti riscontrare problemi di overflow numerico.

25567 + (DATEDIFF(SECOND, {d '1970-01-01'}, @Time) + DATEPART(nanosecond, @Time) / 1.0E + 9) / 86400.0- Fonte: " https://siderite.dev/blog/how-to-translate-t-sql-datetime2-to.html "

Naturalmente, si potrebbe anche Casta DateTimeprima (e, se necessario, di nuovo a DateTime2), ma che ci si perde la precisione e la gamma (tutti prima dell'anno 1753) le prestazioni di DateTime2rispetto DateTimeche sono prolly il 2 più grande e anche allo stesso tempo prolly il 2 meno probabilmente necessario che pone la domanda perché usarlo quando si perdono le conversioni implicite / facili in virgola mobile (numero di giorni) per il vantaggio di addizione / sottrazione / "età" (vs. DateDiff) / Avgcalc che è grande nella mia esperienza.

A proposito, la Avgdata-ora è (o almeno dovrebbe essere) un caso d'uso importante. a) Oltre all'uso per ottenere la durata media quando le date-time (poiché una data-ora di base comune) sono utilizzate per rappresentare la durata (una pratica comune), b) è anche utile ottenere una statistica di tipo dashboard su quale sia la data media- ora è nella colonna data-ora di un intervallo / gruppo di righe. c) Una query ad hoc standard (o almeno dovrebbe essere standard) per monitorare / risolvere i problemi in una colonna che potrebbe non essere mai valida / non più e / o potrebbe essere deprecata è elencare per ogni valore il conteggio delle occorrenze e (se presenti) i Min, Avge Maxdata-ora francobolli associati con quel valore.

DateTime2 è devastante se sei uno sviluppatore di Access che prova a scrivere Now () nel campo in questione. Ho appena effettuato una migrazione di Access -> SQL 2008 R2 e inserito tutti i campi datetime come DateTime2. Aggiungendo un record con Now () quando il valore è esploso. Andava bene il 01/01/2012 alle 14:53:04, ma non il 10/01/2012 alle 14:53:04.

Una volta il personaggio ha fatto la differenza. Spero che aiuti qualcuno.

Ecco un esempio che ti mostrerà le differenze nella dimensione della memoria (byte) e nella precisione tra smalldatetime, datetime, datetime2 (0) e datetime2 (7):

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

che ritorna

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

Quindi, se voglio archiviare le informazioni fino al secondo, ma non al millisecondo, posso salvare 2 byte ciascuno se uso datetime2 (0) invece di datetime o datetime2 (7).

mentre c'è una maggiore precisione con datetime2 , alcuni client non supportano data , ora o datetime2 e ti costringono a convertire in una stringa letterale. In particolare Microsoft menziona i problemi ODBC, OLE DB, JDBC e SqlClient "di basso livello" con questi tipi di dati e ha un diagramma che mostra come ciascuno può mappare il tipo.

Se la compatibilità di valore su precisione, usa datetime

Vecchia domanda ... Ma voglio aggiungere qualcosa che non è già stato dichiarato da nessuno qui ... (Nota: questa è la mia osservazione, quindi non chiedere alcun riferimento)

Datetime2 è più veloce se utilizzato nei criteri di filtro.

TLDR:

In SQL 2016 avevo una tabella con centinaia di migliaia di righe e una colonna datetime ENTRY_TIME perché era necessario memorizzare l'ora esatta fino a secondi. Durante l'esecuzione di una query complessa con molti join e una query secondaria, quando ho usato la clausola where come:

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

La query andava bene inizialmente quando c'erano centinaia di righe, ma quando il numero di righe aumentava, la query iniziava a dare questo errore:

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

Ho rimosso la clausola where e, inaspettatamente, la query è stata eseguita in 1 secondo, sebbene ora TUTTE le righe per tutte le date siano state recuperate. Eseguo la query interna con la clausola where e ci sono voluti 85 secondi e senza la clausola where ci sono voluti 0,01 secondi.

Mi sono imbattuto in molti thread qui per questo problema come prestazioni del filtro datetime

Ho ottimizzato la query un po '. Ma la vera velocità che ho ottenuto è stata cambiando la colonna datetime in datetime2.

Ora la stessa query scaduta in precedenza richiede meno di un secondo.

Saluti

L'interpretazione delle stringhe di date in datetimee datetime2può anche essere diversa, quando si utilizzano le DATEFORMATimpostazioni non statunitensi . Per esempio

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

Questo ritorna 2013-05-06(cioè il 6 maggio) per datetime, e 2013-06-05(cioè il 5 giugno) per datetime2. Tuttavia, con dateformatimpostato su mdy, entrambi @de @d2ritorno 2013-06-05.

Il datetimecomportamento sembra in contrasto con la documentazione MSDN di SET DATEFORMATquali stati: Alcuni formati di stringhe di caratteri, ad esempio ISO 8601, vengono interpretati indipendentemente dall'impostazione DATEFORMAT . Ovviamente non è vero!

Fino a quando non sono stato morso da questo, ho sempre pensato che le yyyy-mm-dddate sarebbero state gestite correttamente, indipendentemente dalle impostazioni di lingua / locale.

Secondo questo articolo , se vuoi avere la stessa precisione di DateTime usando DateTime2 devi semplicemente usare DateTime2 (3). Questo dovrebbe darti la stessa precisione, occupare meno byte e fornire un intervallo ampliato.

Mi sono appena imbattuto in un altro vantaggio per DATETIME2: evita un bug nel adodbapimodulo Python , che esplode se datetimeviene passato un valore di libreria standard che ha microsecondi diversi da zero per una DATETIMEcolonna ma funziona bene se la colonna è definita come DATETIME2.

Select ValidUntil + 1
from Documents

L'SQL sopra non funzionerà con un campo DateTime2. Restituisce ed errore "Operando tipo clash: datetime2 non è compatibile con int"

L'aggiunta di 1 per ottenere il giorno successivo è qualcosa che gli sviluppatori hanno fatto con le date per anni. Ora Microsoft dispone di un nuovissimo campo datetime2 che non è in grado di gestire questa semplice funzionalità.

"Usiamo questo nuovo tipo che è peggio di quello vecchio", non credo!

Penso che DATETIME2sia il modo migliore per conservare il date, perché ha più efficienza del DATETIME. In SQL Server 2008puoi usare DATETIME2, memorizza una data e un'ora, richiede 6-8 bytesper memorizzare e ha una precisione di 100 nanoseconds. Quindi, chiunque avrà bisogno di maggiore precisione nel tempo, lo vorrà DATETIME2.