SMALLDATETIME vs DATETIME2

SMALLDATETIME ma niższą precyzję i węższy zakres dat niż DATETIME2, ale zajmuje mniej miejsca.

SMALLDATETIME vs DATETIME2 – czym różnią się te typy danych

Porównanie SMALLDATETIME i DATETIME2 dotyczy sposobu przechowywania wartości opisujących datę oraz czas w Microsoft SQL Server. Oba typy mogą służyć do zapisywania momentu wystąpienia zdarzenia, na przykład utworzenia dokumentu, rozpoczęcia procesu, przyjęcia zgłoszenia albo wykonania operacji w systemie. Nie są jednak zamiennikami o identycznym działaniu. Różnią się zakresem obsługiwanych dat, dokładnością zapisu, sposobem zaokrąglania sekund, ilością zajmowanego miejsca oraz konsekwencjami dla zapytań i aplikacji.

SMALLDATETIME przechowuje datę wraz z godziną i minutą. Wartość sekund nie jest zachowywana z dokładnością właściwą dla tego typu, dlatego przy zapisie czasu następuje zaokrąglenie. DATETIME2 został zaprojektowany jako dokładniejszy i bardziej elastyczny typ daty oraz czasu. Może przechowywać ułamki sekundy, a poziom dokładności określa się parametrem skali od 0 do 7, na przykład DATETIME2(3) albo DATETIME2(7). Im większa skala, tym więcej informacji o czasie pozostaje w bazie.

W praktyce wybór nie powinien być dokonywany wyłącznie na podstawie rozmiaru kolumny. Istotne jest to, jak dokładnie trzeba odtworzyć moment zdarzenia, jakie daty mogą pojawić się w danych oraz czy kolumna będzie porównywana z wartościami pochodzącymi z innych systemów. Typ, który dziś wydaje się wystarczający, może później utrudniać integrację, analizę historii albo ustalenie kolejności operacji wykonanych w krótkim odstępie czasu.

SMALLDATETIME vs DATETIME2 – kontekst techniczny i porównania

SMALLDATETIME obsługuje zakres od 1 stycznia 1900 roku do 6 czerwca 2079 roku. Jest to zakres wystarczający dla wielu bieżących zastosowań, lecz ograniczony w porównaniu z DATETIME2. Ten drugi typ obejmuje daty od 1 stycznia 0001 roku do 31 grudnia 9999 roku. Różnica może mieć znaczenie w systemach przechowujących bardzo stare dane, planujących terminy odległe w przyszłości albo wymieniających informacje z aplikacjami, które korzystają z szerszego zakresu dat.

W przypadku SMALLDATETIME czas jest zapisywany z dokładnością do minuty. Sekundy od 00 do 29 powodują pozostawienie bieżącej minuty, natomiast sekundy od 30 do 59 mogą spowodować przejście do kolejnej minuty. Oznacza to, że wartość wejściowa nie zawsze będzie równa wartości odczytanej później. Przykładowo zdarzenie zapisane pod koniec minuty może zostać przedstawione jako początek następnej minuty. Przy analizie logów, pomiarów lub kolejności zdarzeń takie zachowanie może prowadzić do niejednoznacznych wyników.

DATETIME2 pozwala świadomie dobrać skalę dokładności. DATETIME2(0) przechowuje pełne sekundy bez części ułamkowej, DATETIME2(3) zapisuje milisekundy, a DATETIME2(7) zapewnia najwyższą dokładność dostępną dla tego typu. W wielu aplikacjach DATETIME2(3) jest rozsądnym kompromisem między szczegółowością a rozmiarem danych. Nie należy jednak przyjmować jednej skali bez sprawdzenia źródła danych, ponieważ system zewnętrzny może przekazywać czas z inną dokładnością.

Oba typy różnią się również reprezentacją wartości podczas konwersji. Jawne rzutowanie jest bezpieczniejsze niż poleganie na automatycznym dopasowaniu typów, zwłaszcza gdy zapytanie łączy kolumny, parametry i literały pochodzące z różnych źródeł. Przy porównywaniu wartości z DATETIME2 i SMALLDATETIME należy pamiętać, że konwersja do mniej dokładnego typu może utracić część informacji, a zaokrąglenie może zmienić wynik warunku.

SMALLDATETIME vs DATETIME2 – typowe problemy w danych

Jednym z częstszych problemów jest użycie SMALLDATETIME do rejestrowania wielu zdarzeń występujących w tej samej minucie. Po zapisaniu wszystkie takie wartości mogą wyglądać tak samo, mimo że operacje odbyły się w różnym czasie. Utrudnia to sortowanie, odtwarzanie przebiegu działań oraz ustalenie, które zdarzenie wystąpiło wcześniej. Jeżeli kilka rekordów ma identyczną datę i godzinę, potrzebny może być dodatkowy klucz porządkujący, lecz nie zastąpi on utraconej informacji o czasie.

Kolejna trudność pojawia się podczas filtrowania przedziału czasowego. Warunek oparty na granicy z sekundami może działać inaczej, niż oczekiwano, jeśli jedna ze stron porównania zostanie sprowadzona do SMALLDATETIME. W konsekwencji rekord znajdujący się blisko końca minuty może zostać przypisany do sąsiedniego przedziału. W raportach dziennych lub minutowych może to zmienić sumy, liczbę zdarzeń i kolejność prezentowanych informacji.

Problemy mogą powstać również przy migracji. Przeniesienie kolumny SMALLDATETIME do DATETIME2 nie odzyska sekund, które wcześniej zostały zaokrąglone lub pominięte. Zwiększenie typu poprawi zakres i przyszłą dokładność, ale nie odtworzy pierwotnego momentu zapisu. Odwrotna konwersja, czyli przejście z DATETIME2 do SMALLDATETIME, może natomiast utracić ułamki sekundy, zmienić minutę i spowodować różnice w indeksach, raportach lub danych używanych do synchronizacji.

Warto zwrócić uwagę na wartości domyślne, procedury składowane, parametry aplikacji oraz formaty importowanych plików. Sama definicja kolumny nie opisuje całego przepływu czasu przez system. Znaczenie mają także ustawienia sterownika, sposób serializacji, strefa czasowa oraz to, czy zapisywany jest czas lokalny, czy czas uniwersalny. SMALLDATETIME i DATETIME2 nie rozwiązują samodzielnie problemu stref czasowych, ponieważ przechowują wartość daty i czasu, a nie pełną informację o lokalizacji geograficznej.

SMALLDATETIME vs DATETIME2 – praktyczne wskazówki wyboru

SMALLDATETIME można rozważyć wtedy, gdy dane rzeczywiście mają znaczenie wyłącznie na poziomie minuty, zakres dat pozostaje w jego granicach, a utrata sekund nie wpływa na działanie aplikacji. Przykładem może być prosty harmonogram, w którym użytkownik wybiera termin z dokładnością do minuty, pod warunkiem że wymagania systemu nie przewidują późniejszej obsługi dokładniejszych danych. Przed wyborem należy jednak sprawdzić, czy wartość nie będzie używana jako znacznik kolejności albo element mechanizmu synchronizacji.

DATETIME2 jest zazwyczaj właściwszy, gdy wymagane są sekundy lub ułamki sekund, gdy dane będą wymieniane z nowoczesnymi aplikacjami, gdy zakres dat powinien być szeroki albo gdy przewiduje się rozwój modelu danych. Dobrą praktyką jest określenie skali zgodnie z rzeczywistą potrzebą. Nie zawsze najwyższa dostępna dokładność jest konieczna, lecz równie niebezpieczne jest ustawienie zbyt małej dokładności bez analizy źródeł danych.

Podczas projektowania tabeli warto opisać przeznaczenie każdej kolumny. Należy ustalić, czy zapisywany jest moment utworzenia rekordu, rozpoczęcia zdarzenia, jego zakończenia, czy może data biznesowa niezwiązana z chwilą wykonania operacji. Dla każdej wartości powinno być jasne, czy część czasowa ma znaczenie oraz jakie reguły obowiązują przy braku wartości. Pomaga to uniknąć późniejszego mieszania dat kalendarzowych ze znacznikami czasu.

Przy zmianie typu należy najpierw wykonać kopię danych, sprawdzić wartości graniczne i przetestować zapytania korzystające z kolumny. Należy porównać wyniki przed i po konwersji dla rekordów położonych blisko początku oraz końca minuty. Warto także skontrolować indeksy, sortowanie, warunki zakresowe, raporty i integracje. Szczególną uwagę trzeba poświęcić parametrom przekazywanym przez aplikację, ponieważ typ w kodzie może być automatycznie dopasowywany do typu kolumny w sposób nieoczywisty.

SMALLDATETIME vs DATETIME2 – kiedy zgłosić się do serwisu

Do serwisu warto zgłosić się wtedy, gdy różnice między czasem zapisanym w aplikacji a czasem widocznym w bazie powtarzają się, rekordy otrzymują nieoczekiwaną minutę albo raporty pokazują zdarzenia w niewłaściwej kolejności. Sygnałem ostrzegawczym są także trudności z migracją, błędy podczas porównywania dat, rozbieżności między środowiskiem testowym i produkcyjnym oraz problemy z importem danych zawierających milisekundy. Przed przekazaniem sprawy pomocne jest przygotowanie przykładowych wartości wejściowych, wartości zapisanych w tabeli, fragmentu definicji kolumny i zapytania, które zwraca niepoprawny wynik.

Warszawskie Pogotowie Komputerowe 24/7 może pomóc w uporządkowaniu problemu od strony stanowiska komputerowego, konfiguracji aplikacji oraz współpracy z bazą danych. Przy analizie należy rozdzielić błąd wynikający z samego typu danych od błędu konwersji, formatu daty, ustawień programu lub niewłaściwego warunku w zapytaniu. Takie rozróżnienie pozwala dobrać rozwiązanie bez przypadkowej zmiany kolumn, która mogłaby wpłynąć na istniejące dane.

Przed zgłoszeniem warto zanotować nazwę używanego systemu bazodanowego, przykład problematycznego rekordu, oczekiwany rezultat oraz faktyczny rezultat wyświetlany przez program. Nie powinno się usuwać danych ani wykonywać masowej konwersji bez sprawdzenia kopii zapasowej i planu odtworzenia. Odpowiednio zebrane informacje ułatwiają ocenę, czy wystarczy korekta zapytania, zmiana sposobu przekazywania parametrów, aktualizacja definicji kolumny, czy szersza analiza działania aplikacji.