SCHEMA_BINDING w temporal tables

SCHEMA_BINDING w tabelach temporalnych chroni spójność struktury historii przed niekontrolowanymi zmianami.

SCHEMA_BINDING a system-versioned temporal table

SCHEMA_BINDING oznacza związanie definicji obiektu z określonym schematem danych. Warto jednak rozróżnić nazwę tego mechanizmu od zasad obowiązujących w system-versioned temporal tables programu Microsoft SQL Server. SQL Server udostępnia opcję WITH SCHEMABINDING przede wszystkim dla widoków i funkcji użytkownika. Nie jest to osobna opcja włączenia historii dla tabeli temporalnej ani nazwa parametru zastępującego SYSTEM_VERSIONING = ON.

W przypadku tabel temporalnych podobny cel realizuje kontrola zgodności tabeli bieżącej z tabelą historii. Tabela temporalna przechowuje aktualny stan danych, natomiast tabela historii zachowuje poprzednie wersje wierszy. SQL Server wymaga, aby obie struktury były zgodne między innymi pod względem liczby kolumn, ich nazw, kolejności oraz typów danych. Dzięki temu zapis starszej wersji wiersza nie trafia do tabeli o niepasującym układzie.

Jak SQL Server pilnuje zgodności tabeli historii

System-versioned temporal table musi mieć klucz główny oraz dokładnie jedną definicję PERIOD FOR SYSTEM_TIME. Okres ważności wiersza opisują dwie kolumny typu datetime2, zwykle oznaczane jako początek i koniec okresu. Kolumny te są deklarowane jako generowane przez system, a silnik wykorzystuje je do ustalenia, w jakim przedziale czasu dany wiersz był aktualny.

Podczas utworzenia tabeli można wskazać istniejącą tabelę historii za pomocą opcji HISTORY_TABLE. SQL Server sprawdza wtedy jej zgodność z tabelą bieżącą. Nieprawidłowa liczba kolumn, różne typy danych albo niezgodny układ kolumn powodują odrzucenie operacji. Jeżeli tabela historii nie zostanie wskazana, silnik może utworzyć ją automatycznie. W obu przypadkach jej struktura musi umożliwiać przechowywanie poprzednich wersji danych.

Zmiany schematu przy włączonym wersjonowaniu

Zmiana struktury tabeli temporalnej nie powinna być traktowana jak zwykła, niezależna modyfikacja tabeli bieżącej. Przy włączonym system versioningu SQL Server wykonuje operacje schematu z uwzględnieniem tabeli historii. Dodanie, zmiana albo usunięcie kolumny musi zachować wymagane dopasowanie obu tabel. Podczas takiej operacji silnik uzyskuje blokadę schematu na tabeli bieżącej i historii.

W praktyce administrator powinien sprawdzić oba obiekty przed wykonaniem ALTER TABLE, szczególnie gdy tabela historii została utworzona ręcznie albo jest używana przez procesy raportowe. Do kontroli konfiguracji można wykorzystać między innymi widoki katalogowe SQL Server, takie jak sys.tables oraz sys.periods. Informacja o powiązanej tabeli historii jest przechowywana w metadanych tabeli temporalnej. Jeżeli modyfikacja wymaga szerszej przebudowy, bezpiecznym podejściem jest czasowe wyłączenie wersjonowania, wykonanie zgodnych zmian w obu strukturach i ponowne włączenie mechanizmu po sprawdzeniu danych.

Skutki błędnego rozumienia SCHEMA_BINDING

Utożsamienie SCHEMA_BINDING z ochroną tabeli temporalnej może prowadzić do nieprawidłowej diagnozy. Samo użycie SCHEMABINDING w widoku nie zapewnia automatycznego zapisywania historii zmian tabeli. Z kolei włączenie SYSTEM_VERSIONING nie oznacza, że każdy zależny widok lub funkcja zostaną automatycznie zabezpieczone przed zmianą definicji. Są to różne mechanizmy działające na różnych obiektach bazy.

Podczas diagnostyki należy więc ustalić, czy problem dotyczy blokady zależności widoku, czy niespójności pary tabela bieżąca–tabela historii. W drugim przypadku trzeba zweryfikować definicję kolumn, kolumny okresu, klucz główny, ustawienie SYSTEM_VERSIONING oraz komunikat zwrócony przez silnik przy operacji DDL. Taka kontrola pozwala odróżnić rzeczywiste naruszenie wymagań temporal table od błędu w definicji obiektu korzystającego z SCHEMABINDING.