Le dimensioni di dateTime2 (0), dateTime2 (1), dateTime2 (2), dateTime2 (3) utilizzano la stessa quantità di memoria. (6 byte)
Sarei corretto nel dire che potrei anche andare con dateTime2 (3) e ottenere il vantaggio della precisione senza costi di dimensioni aggiuntive.
No, hai interpretato male la documentazione. Si noti che il documento indica una dimensione di archiviazione di 6 byte per precisioni inferiori a 3 (sottolineatura mia). Quindi una precisione pari a 3 richiederà 7 byte.
Se non ti interessa i millisecondi, datetime2(0)sarebbe il tipo di dati e la precisione corretti. La migliore pratica è quella di specificare il tipo di dati e la precisione adeguati in base ai dati archiviati poiché ciò fornirà intrinsecamente archiviazione ed efficienza ottimali. Detto questo, non mi aspetto un impatto significativo sulle prestazioni in base alla precisione datetime2 specificata, purché la dimensione dello spazio di archiviazione sia la stessa, ma non l'ho testato specificamente.
I requisiti dell'applicazione determineranno ciò che deve essere archiviato nel database quando è disponibile una maggiore precisione nell'origine. Ad esempio, per un tempo di immissione dell'ordine da cui provengono SYSDATETIME(), gli utenti potrebbero non voler una precisione di 100 nanosecondi. Ancora una volta, scegli il tipo di dati e la precisione per il nuovo sviluppo in base ai requisiti e otterrai generalmente prestazioni ottimali senza pensarci troppo:
- data - non hai bisogno di tempo
- smalldatetime - non hai bisogno di secondi
- datetime2 (0) - non sono necessari secondi frazionari
- datetime2 (1-7) - sono necessari secondi frazionari della precisione specificata
- datetimeoffset (0-7) : sono necessari la data e l'ora con la consapevolezza del fuso orario
- ora (0-7) - è necessario solo il tempo (nessuna data) con secondi frazionari della precisione specificata
Sebbene datetime2 sia più appropriato per il nuovo sviluppo come elencato sopra, a volte potrebbe essere necessario utilizzare datetime (precisione fissa 3 con precisione di 1/300 di secondo frazionario) invece per la compatibilità con applicazioni datetime legacy, evitando così conversioni implicite e comportamento di confronto imprevisto, ma a il costo della seconda precisione frazionaria e una maggiore conservazione.
Considerare che la memorizzazione di una precisione maggiore di quella necessaria può comportare anche un costo di sviluppo. Se si memorizza un componente temporale con secondi frazionari quando è richiesta solo la precisione di un secondo intero, le query dovranno comunque considerare i secondi frazionari per restituire i risultati corretti. Ad esempio, con un'app in cui l'utente seleziona un intervallo di tempo tramite un'interfaccia utente che consente solo secondi interi, il codice dell'app dovrebbe tenere conto dei secondi frazionari nel valore dell'intervallo di tempo finale e regolare di conseguenza il valore fornito dall'utente (ad es. WHERE OrderEntryTime BETWEEN '2017-01-11T08:00:00.00.00' AND '2017-01-11T08:59:59.99'o WHERE OrderEntryTime >= '2017-01-11T08:00:00.00' AND OrderEntryTime < '2017-01-11T09:00:00.00'). Ciò aggiungerà complessità al codice.