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ń:
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.
smalldatetimeSELECT CAST(GETDATE() AS smalldatetime);