datetime2 (0) vs datetime2 (2)

Zgodnie z dokumentacją datetime2 (Transact-SQL) :

Rozmiar pamięci
6 bajtów dla dokładności mniejszych niż 3,7
bajtów dla dokładności 3 i 4.
Wszystkie pozostałe dokładności wymagają 8 bajtów.

Wielkość datetime2(0), datetime2(1), datetime2(2)wykorzystać taką samą ilość do przechowywania (6 bitów).

Czy miałbym rację mówiąc, że równie dobrze mogę datetime2(2)skorzystać z precyzji bez dodatkowych kosztów związanych z rozmiarem?

Proszę zanotować:

• Ta kolumna jest indeksowana za pomocą PK w celu utworzenia złożonego indeksu klastrowego (używanego do partycjonowania tabeli)
• Nie dbam o milisekundy

Czy datetime2(0)procesor byłby bardziej wydajny, gdyby był użyty w klauzuli where lub podczas przeszukiwania indeksu?

To ogromny stół, więc najmniejsza optymalizacja zrobi dużą różnicę.

Rozmiar dateTime2 (0), dateTime2 (1), dateTime2 (2), dateTime2 (3) używają tej samej ilości pamięci. (6 bajtów)

Czy miałbym rację mówiąc, że równie dobrze mogę przejść do dateTime2 (3) i zyskać na precyzji bez dodatkowych kosztów związanych z rozmiarem?

Nie, źle zinterpretowałeś dokumentację. Zwróć uwagę, że dokument określa wielkość pamięci 6 bajtów dla dokładności mniejszych niż 3 (moje podkreślenie). Tak więc precyzja równa 3 będzie wymagać 7 bajtów.

Jeśli nie zależy Ci na milisekundach, datetime2(0)będzie to właściwy typ danych i precyzja. Najlepszą praktyką jest określenie właściwego typu danych i precyzji na podstawie przechowywanych danych, ponieważ z natury zapewni to optymalne przechowywanie i wydajność. Biorąc to pod uwagę, nie spodziewałbym się znaczącego wpływu na wydajność w oparciu o określoną precyzję datetime2, o ile rozmiar pamięci jest taki sam, ale osobiście tego nie testowałem.

Wymagania aplikacji będą decydować o tym, co musi być przechowywane w bazie danych, gdy w źródle dostępna jest większa precyzja. Na przykład, dla czasu wejścia zamówienia pochodzącego od SYSDATETIME(), użytkownicy mogą nie chcieć dokładności 100 nanosekund. Ponownie wybierz typ danych i precyzję nowego opracowania zgodnie z wymaganiami, a na ogół uzyskasz optymalną wydajność bez dodatkowych przemyśleń:

• data - nie potrzebujesz czasu
• smalldatetime - nie potrzebujesz sekund
• datetime2 (0) - nie potrzebujesz ułamków sekund
• datetime2 (1-7) - potrzebujesz ułamków sekund o określonej precyzji
• datetimeoffset (0-7) - potrzebujesz daty i godziny ze świadomością strefy czasowej
• czas (0–7) - potrzebujesz tylko czasu (bez daty) z ułamkami sekund o określonej precyzji

Chociaż datetime2 jest najbardziej odpowiedni dla nowych prac rozwojowych wymienionych powyżej, czasami może być konieczne użycie datetime (stała precyzja 3 z dokładnością 1/300 ułamków sekund) zamiast tego w celu zapewnienia zgodności ze starszymi aplikacjami datetime, unikając w ten sposób niejawnych konwersji i nieoczekiwanych zachowań porównawczych, ale w koszt ułamkowej sekundy dokładności i zwiększonego przechowywania.

Weź pod uwagę, że przechowywanie większej precyzji niż jest to wymagane, może również wiązać się z kosztami rozwoju. Jeśli ktoś przechowuje komponent czasu z ułamkami sekund, gdy wymagana jest tylko cała sekunda dokładności, zapytania nadal będą musiały wziąć pod uwagę ułamki sekund, aby zwrócić prawidłowe wyniki. Na przykład w przypadku aplikacji, w której użytkownik wybiera zakres czasu za pomocą interfejsu użytkownika, który pozwala tylko na całe sekundy, kod aplikacji musiałby uwzględniać ułamkowe sekundy wartości końcowej zakresu czasu i odpowiednio dostosowywać wartość podaną przez użytkownika (np. WHERE OrderEntryTime BETWEEN '2017-01-11T08:00:00.00.00' AND '2017-01-11T08:59:59.99'lub WHERE OrderEntryTime >= '2017-01-11T08:00:00.00' AND OrderEntryTime < '2017-01-11T09:00:00.00'). Zwiększy to złożoność kodu.