Temporal tables vs Change Tracking

Tabele temporalne rejestrują wersje wierszy automatycznie, podczas gdy Change Tracking śledzi jedynie sam fakt zmiany.

Dwa mechanizmy śledzenia zmian w SQL Server

Temporal tables, nazywane także tabelami czasowymi lub tabelami systemowo wersjonowanymi, przechowują bieżący stan danych oraz wcześniejsze wersje wierszy. SQL Server automatycznie zapisuje poprzednią wersję w tabeli historii, gdy wiersz zostanie zmieniony albo usunięty. Dzięki temu można odtworzyć stan rekordu z określonego momentu lub przeanalizować przedział czasu, w którym obowiązywała konkretna wartość. Mechanizm opiera się na dwóch kolumnach okresu ważności, zwykle definiowanych jako GENERATED ALWAYS AS ROW START i GENERATED ALWAYS AS ROW END, oraz na tabeli historii wskazanej w definicji tabeli systemowo wersjonowanej.

Change Tracking działa inaczej. Rejestruje fakt zmiany wiersza, jego klucz oraz rodzaj operacji, na przykład wstawienie, aktualizację albo usunięcie. Nie przechowuje pełnej kopii poprzednich wartości i nie jest mechanizmem odtwarzania historycznego obrazu tabeli. Aplikacja może pobrać informację o zmianach od określonej wersji śledzenia, a następnie odczytać aktualne dane z tabeli podstawowej. Z tego powodu oba rozwiązania służą do innych celów, mimo że dotyczą wykrywania zmian w danych.

Historia wartości a informacja o zmianie

Najważniejsza różnica dotyczy zawartości rejestrowanych informacji. Tabela temporalna pozwala odpowiedzieć na pytanie, jaka wartość znajdowała się w wierszu przed zmianą oraz w jakim okresie była obowiązująca. Jeżeli kolumna adresu lub statusu zostanie zaktualizowana, poprzedni zestaw wartości trafia do tabeli historii. Zapytanie temporalne może następnie zwrócić dane obowiązujące w określonym punkcie czasu albo wszystkie wersje mieszczące się w wybranym przedziale.

Change Tracking nie odpowiada na pytanie, jaka była poprzednia wartość. Informuje natomiast, że konkretny wiersz został zmieniony od czasu wskazanej wersji oraz może wskazać zmienione kolumny, jeżeli włączono śledzenie zmian kolumn. W przypadku usunięcia rekordu informacja o zmianie pozostaje dostępna wraz z jego kluczem, ale mechanizm nie zapewnia pełnej treści usuniętego wiersza. Odczyt danych wykonywany po wykryciu zmiany zwraca zatem bieżący stan, a nie stan sprzed modyfikacji.

Wybór mechanizmu zależnie od przepływu danych

Temporal tables są właściwe wtedy, gdy wymagane jest zachowanie historii wartości i możliwość późniejszej analizy zmian. Przykładowym zastosowaniem jest odtworzenie konfiguracji rekordu z określonego czasu, porównanie kolejnych wersji albo ustalenie, kiedy dana wartość zaczęła obowiązywać. Historia zwiększa jednak ilość przechowywanych danych, ponieważ kolejne wersje zmienianych wierszy są zapisywane w tabeli historii. Przy częstych aktualizacjach trzeba uwzględnić jej rozmiar, indeksowanie oraz sposób archiwizacji.

Change Tracking pasuje do synchronizacji, odświeżania lokalnego zbioru danych i innych scenariuszy, w których wystarczy ustalenie, które rekordy wymagają ponownego odczytu. Mechanizm przechowuje znacznie mniej informacji niż historia temporalna, dlatego może być użyteczny, gdy aplikacja nie musi znać poprzednich wartości. Trzeba jednak pilnować okresu przechowywania informacji o zmianach. Jeżeli aplikacja poprosi o zmiany starsze niż dostępne w konfiguracji śledzenia, nie będzie mogła bezpiecznie wykonać przyrostowej synchronizacji i może być konieczne ponowne pobranie całego zbioru.

Nie należy traktować Change Tracking jako zamiennika audytu ani zakładać, że temporal table sama rozwiązuje wszystkie problemy synchronizacji. Tabela temporalna opisuje wersje danych, natomiast Change Tracking dostarcza aplikacji punktu odniesienia do wykrywania nowych modyfikacji. Przy projektowaniu rozwiązania trzeba także uwzględnić transakcje, klucze główne, opóźnienie odczytu oraz zachowanie aplikacji po utracie lub przedawnieniu wersji śledzenia.

Sprawdzanie konfiguracji i diagnostyka działania

Diagnostyka powinna rozpocząć się od ustalenia, który mechanizm został faktycznie włączony dla danej tabeli. W przypadku tabel temporalnych należy sprawdzić obecność kolumn okresu, ustawienie wersjonowania systemowego oraz powiązanie z tabelą historii. Istotne jest również potwierdzenie, że zapytania korzystają z właściwej tabeli i odpowiedniej składni temporalnej, zamiast odczytywać wyłącznie bieżące rekordy. Sam fakt istnienia tabeli historii nie oznacza jeszcze, że aplikacja wykorzystuje ją do odtwarzania danych.

Przy Change Tracking trzeba zweryfikować, czy śledzenie jest włączone na poziomie bazy danych i konkretnej tabeli, jaka jest aktualna wersja śledzenia oraz czy aplikacja prawidłowo przechowuje ostatnią przetworzoną wersję. Błędy przepływu danych często wynikają z użycia zbyt starej wersji synchronizacji, pominięcia usuniętych rekordów albo odczytu bieżących danych bez obsługi sytuacji, w której rekord został skasowany. Diagnostyka powinna porównać oczekiwany zakres zmian z rzeczywistym wynikiem zapytań i z logiką zatwierdzania kolejnych wersji przez aplikację.

Przy problemach z historią danych na komputerze używanym do pracy z SQL Server warto rozdzielić błąd samego silnika od problemu aplikacji, połączenia lub narzędzia administracyjnego. Należy sprawdzić komunikaty błędów, uprawnienia do odczytu tabeli podstawowej i historii, poprawność zapytań oraz dostępne miejsce na dysku. Diagnostyka sprzętu może obejmować nośnik danych, pamięć operacyjną i stabilność systemu, ponieważ awarie tych elementów mogą powodować przerwane operacje lub błędy odczytu, ale nie zmieniają semantyki Temporal Tables ani Change Tracking.