Ograniczenia temporal tables

Tabele temporalne mają ograniczenia w zakresie modyfikacji schematu i nie pozwalają na dowolną edycję historii.

Na czym polegają ograniczenia tabel temporalnych

Tabele temporalne przechowują bieżący stan rekordów oraz informacje o ich wcześniejszych wersjach. W implementacji system-versioned temporal tables w Microsoft SQL Server tabela główna jest powiązana z tabelą historii, a system automatycznie zapisuje poprzednią wersję wiersza przy aktualizacji lub usunięciu danych. Każdy rekord wersjonowany ma dwa znaczniki czasu określające początek i koniec okresu obowiązywania. Mechanizm ten pozwala odtworzyć stan danych z określonego momentu, ale jednocześnie nakłada dodatkowe reguły na operacje wykonywane na tabeli.

Najważniejsze ograniczenie dotyczy historii. Przy włączonym SYSTEM_VERSIONING użytkownik nie może dowolnie zmieniać ani usuwać wierszy z tabeli historii zwykłym poleceniem UPDATE lub DELETE. Historia jest zarządzana przez silnik, ponieważ jej spójność zależy od relacji między tabelą bieżącą, tabelą historii oraz kolumnami okresu. Oznacza to, że temporal tables nie są zwykłym mechanizmem tworzenia kopii zapasowej. Zapisane wersje powinny być traktowane jako wynik kontrolowanego śledzenia zmian, a nie obszar przeznaczony do ręcznej korekty.

Zmiany schematu przy włączonym wersjonowaniu

Wersjonowanie systemowe wymaga zgodności schematu tabeli bieżącej i tabeli historii. Obie tabele muszą mieć odpowiadające sobie kolumny przeznaczone do przechowywania kolejnych wersji danych, a tabela bieżąca musi zawierać kolumny okresu zdefiniowane jako GENERATED ALWAYS AS ROW START oraz GENERATED ALWAYS AS ROW END. Jeżeli zmiana struktury narusza tę zgodność, SQL Server odrzuci operację albo będzie wymagał wcześniejszego wyłączenia SYSTEM_VERSIONING. Dotyczy to między innymi zmian typów kolumn, usuwania kolumn oraz części operacji wpływających na definicję okresu.

Dodanie kolumny lub modyfikacja istniejącego schematu wymaga sprawdzenia obu tabel, a nie tylko tabeli bieżącej. W zależności od rodzaju operacji SQL Server może wykonać odpowiednią zmianę w obu miejscach, lecz nie należy zakładać, że każda instrukcja ALTER TABLE będzie obsługiwana automatycznie. Szczególnej uwagi wymagają kolumny z ograniczeniem NOT NULL, ponieważ tabela historii musi być zdolna do przyjęcia wszystkich wersji wierszy. Zmiana schematu może również wymagać dostarczenia wartości domyślnej albo przebudowy tabeli, co przy dużym zbiorze danych wpływa na czas blokowania i obciążenie systemu.

Dlaczego historii nie można poprawiać dowolnym poleceniem

Historia w tabeli temporalnej jest tworzona na podstawie operacji wykonanych na tabeli bieżącej. Gdy rekord zostaje zmieniony, poprzednia wersja otrzymuje czas zakończenia, a nowa wersja pozostaje w tabeli bieżącej z nowym początkiem okresu. Przy usunięciu rekordu jego ostatnia wersja trafia do tabeli historii. Ręczne zmienienie wartości albo przedziału czasu mogłoby spowodować nakładanie się okresów, przerwy między wersjami lub sytuację, w której zapytanie FOR SYSTEM_TIME zwróci wynik niezgodny z rzeczywistą kolejnością zmian.

Jeżeli konieczna jest administracyjna korekta historii, typowym warunkiem jest wyłączenie wersjonowania systemowego dla danej tabeli. Po ustawieniu SYSTEM_VERSIONING = OFF tabela historii staje się dostępna do operacji, które wcześniej były blokowane, ale odpowiedzialność za zachowanie spójności przechodzi na administratora. Po zakończeniu zmian trzeba ponownie włączyć wersjonowanie i wskazać prawidłową tabelę historii. Przed taką operacją należy sprawdzić kolumny okresu, zakresy dat oraz relację między tabelą główną i historyczną. Błędna korekta może sprawić, że późniejsze zapytania temporalne będą formalnie wykonalne, lecz ich wyniki przestaną wiarygodnie przedstawiać przebieg zmian.

Skutki ograniczeń dla diagnostyki bazy danych

Podczas analizy problemu z tabelą temporalną trzeba rozdzielić trzy kwestie: definicję tabeli bieżącej, definicję tabeli historii oraz stan konfiguracji SYSTEM_VERSIONING. Przydatne jest sprawdzenie metadanych tabel temporalnych w widokach katalogowych SQL Server, w szczególności właściwości określających tabelę historii, kolumny początku i końca okresu oraz bieżący stan wersjonowania. Sama obecność starszych rekordów nie potwierdza jeszcze poprawności mechanizmu. Należy również zweryfikować, czy przedziały czasowe są uporządkowane i czy zapytania używają właściwego wariantu FOR SYSTEM_TIME, takiego jak AS OF, FROM ... TO, BETWEEN ... AND albo CONTAINED IN.

Ograniczenia temporal tables mają więc znaczenie zarówno przy projektowaniu schematu, jak i podczas naprawy błędów danych. Przed zmianą struktury należy ustalić, czy operacja jest wspierana przy aktywnym wersjonowaniu, oraz przygotować kontrolowaną procedurę dla tabeli historii. Przed ręczną korektą zapisów trzeba zachować kopię danych i udokumentować zakres modyfikacji, ponieważ wyłączenie SYSTEM_VERSIONING usuwa automatyczną ochronę przed niespójnością, ale nie naprawia jej samoistnie. W środowisku z dużą tabelą historii warto dodatkowo uwzględnić indeksy, rozmiar logu transakcyjnego i czas potrzebny na zmianę schematu. Dzięki temu ograniczenia mechanizmu są traktowane jako element modelu danych, a nie jako przypadkowy błąd podczas wykonywania polecenia.