Wersjonowanie bazy danych

Wersjonowanie bazy danych umożliwia śledzenie zmian schematu i danych w czasie, np. przez tabele temporalne.

Na czym polega wersjonowanie bazy danych

Wersjonowanie bazy danych oznacza rejestrowanie zmian zachodzących w strukturze bazy, a w wielu rozwiązaniach również w przechowywanych rekordach. Wersja schematu opisuje konkretny stan tabel, kolumn, indeksów, ograniczeń, widoków, procedur i innych obiektów. Dzięki temu można ustalić, jakie zmiany zostały wprowadzone, w jakiej kolejności oraz z jaką wersją aplikacji powinien współpracować dany schemat. W praktyce zmiany są często zapisywane w postaci uporządkowanych migracji, czyli skryptów wykonujących określone operacje na bazie.

Wersjonowanie schematu nie jest tym samym co wykonywanie kopii zapasowych. Kopia pozwala odtworzyć dane z określonego momentu, natomiast migracja opisuje zmianę, która prowadzi z jednego stanu struktury do następnego. Przykładowo osobne migracje mogą dodawać kolumnę, tworzyć indeks, zmieniać ograniczenie integralności albo usuwać nieużywany obiekt. Każda migracja powinna mieć jednoznaczny identyfikator i ustaloną kolejność, aby środowisko testowe, produkcyjne oraz lokalna instalacja aplikacji mogły osiągnąć zgodny stan.

Migracje schematu i kontrola kolejności zmian

Narzędzia do migracji zwykle przechowują w bazie techniczną informację o zastosowanych zmianach. Podczas uruchamiania aplikacji albo osobnego procesu wdrożeniowego porównywany jest stan zapisany w tej tabeli z listą dostępnych migracji. Następnie wykonywane są tylko te operacje, których jeszcze nie zastosowano. Takie podejście ogranicza ryzyko wielokrotnego wykonania tej samej zmiany, ale wymaga zachowania spójności między plikami migracji a rzeczywistym stanem bazy.

Zmiana struktury powinna uwzględniać sposób działania kodu korzystającego z bazy. Dodanie opcjonalnej kolumny jest zazwyczaj mniej ryzykowne niż natychmiastowe dodanie kolumny wymaganej, ponieważ starsza wersja aplikacji może nadal zapisywać rekordy bez nowej wartości. Przy zmianach powodujących niezgodność często stosuje się etap przejściowy: najpierw dodaje się nowy obiekt, później aktualizuje kod i dane, a dopiero na końcu usuwa element historyczny. Przed zastosowaniem migracji trzeba również sprawdzić, czy istniejący indeks, klucz obcy lub ograniczenie unikalności nie uniemożliwi wykonania operacji na aktualnych danych.

Historia rekordów dzięki tabelom temporalnym

Wersjonowanie danych pozwala przechowywać nie tylko bieżącą wartość rekordu, lecz także jego wcześniejsze stany. Jednym ze sposobów jest tabela historii, do której trafia kopia rekordu przed zmianą albo po zmianie. Taki model wymaga ustalenia, które zdarzenia są rejestrowane, jak identyfikowany jest rekord źródłowy oraz w jaki sposób przechowywany jest czas obowiązywania danej wersji. Należy rozróżnić czas faktycznego zapisu od czasu, w którym dana wartość była uznawana za obowiązującą, ponieważ te informacje mogą się różnić.

Tabele temporalne wykorzystują przedziały czasu lub znaczniki początku i końca obowiązywania wiersza. Zapytanie o stan danych na konkretny dzień powinno uwzględniać te pola oraz właściwe granice przedziału, aby nie zwrócić jednocześnie dwóch wersji tego samego rekordu. Przydatne są także informacje o rodzaju operacji, na przykład utworzeniu, aktualizacji lub usunięciu. Historia zwiększa rozmiar bazy i może wpływać na wydajność zapisów, dlatego trzeba określić zasady indeksowania, retencji oraz archiwizacji. Nie należy usuwać rekordów historii bez sprawdzenia, czy nie są potrzebne do audytu technicznego, odtworzenia przebiegu zmian albo analizy błędnych aktualizacji.

Sprawdzanie spójności wersji przed użyciem

Podczas diagnozowania problemu z aplikacją korzystającą z bazy warto porównać oczekiwaną wersję schematu z wersją faktycznie zastosowaną. Istotne są między innymi brakujące kolumny, różne typy danych, nieobecne indeksy, rozbieżne ograniczenia oraz migracje wykonane w innej kolejności niż zakładano. Sam fakt, że aplikacja uruchamia się bez błędu, nie potwierdza pełnej zgodności. Niektóre problemy ujawniają się dopiero przy zapisie określonego rekordu, odczycie danych historycznych albo wykonaniu zapytania wymagającego konkretnego indeksu.

Bezpieczna procedura obejmuje kopię zapasową, odtworzenie migracji w środowisku testowym oraz sprawdzenie wyników na danych reprezentujących rzeczywiste przypadki użycia. Trzeba obserwować błędy naruszenia kluczy, niezgodności typów, utratę wartości podczas konwersji i nieoczekiwany wzrost czasu wykonywania zapytań. Wersjonowanie nie zastępuje testów integralności ani monitorowania kopii zapasowych. Jeżeli historia danych ma służyć do odtworzenia zmian, należy dodatkowo zweryfikować, czy operacje aktualizacji i usuwania rzeczywiście tworzą kompletne wpisy oraz czy zegar systemowy i strefa czasowa są interpretowane konsekwentnie.