Tabela _revision_sql w bazie danych SQL Server

Autor: Adam Siemiątkowski, SoftwareStudio Group Sp. z o.o.

Do czego służy tabela [dbo].[_revision_sql]

Aktualizacja systemu magazynowego rzadko sprowadza się do podmiany plików. Dochodzą kolumny, zmieniają się definicje zapytań, powstają nowe pozycje menu. Po roku pytanie „skąd wzięła się ta zmiana i kto ją wprowadził” bywa trudniejsze, niż powinno. Tabela [dbo].[_revision_sql] odpowiada na nie, prowadząc dziennik zmian systemowych.

Kluczowe jest rozróżnienie w kolumnie CUSTOM. Zmiany rozwiązania podstawowego przychodzą z aktualizacją i dotyczą wszystkich instalacji. Modyfikacje oznaczone jako niestandardowe powstały na potrzeby konkretnego klienta i istnieją tylko u niego. To rozróżnienie decyduje o tym, czy przy najbliższej aktualizacji zmiana zostanie zachowana, czy nadpisana.

Opis o pojemności pięciu tysięcy znaków jest tu polem najważniejszym i jednocześnie najczęściej zaniedbywanym. Wpis „poprawki” nie mówi nic; wpis wskazujący, która definicja została zmieniona i po co, oszczędza godzin pracy przy późniejszej diagnozie. Numer rewizji i numer wersji pozwalają zebrać powiązane wpisy w spójną całość.

ZmianaModyfikacja konfiguracji lub struktury bazy danych

→

PochodzenieZnacznik rozdziela rozwiązanie podstawowe od wdrożeniowego

→

AutorLogin i rola osoby, która wprowadziła modyfikację

→

KontekstNumer rewizji i wersja wiążące powiązane wpisy

Rozróżnienie pochodzenia zmiany rozstrzyga, czy przetrwa ona najbliższą aktualizację systemu.

Budowa tabeli — wykaz kolumn

Dziewięć kolumn opisuje samą zmianę, jej autora oraz kontekst wydania.

Kolumna DATA_ZMIAN i KIEDY nie są tym samym: pierwsza to moment wprowadzenia zmiany w bazie, druga — moment zapisania wpisu w dzienniku. Przy zmianach dokumentowanych po fakcie obie wartości się różnią.

Tabela bez klucza głównego — co z tego wynika

W definicji tej tabeli nie zdefiniowano żadnego indeksu, również klucza głównego. Przy kilkuset wpisach nie ma to praktycznego znaczenia, ale warto rozumieć konsekwencje.

Kolumna ID_REVISION_SQL jest oznaczona jako wymagana i pełni rolę identyfikatora, brakuje jej jedynie formalnego ograniczenia.

Dziennik zmian systemowych rośnie znacznie wolniej niż rejestry operacyjne — przy typowym wdrożeniu to kilkadziesiąt wpisów rocznie. Uzupełnienie indeksów jest więc raczej porządkiem niż pilną potrzebą. Warto je jednak rozważyć przy instalacjach utrzymywanych od wielu lat albo obsługujących kilka baz z jednego miejsca.

Jak korzystać z tabeli w praktyce

Przy prowadzeniu dziennika zmian systemowych obowiązują następujące zasady:

• Opisuj zmianę tak, żeby dało się ją zrozumieć bez dostępu do samej bazy — nazwa zmienionej definicji i powód wystarczą.
• Ustawiaj znacznik CUSTOM zgodnie ze stanem faktycznym; to on rozstrzyga, czy zmiana przetrwa aktualizację.
• Wypełniaj kolumnę WERSJA przy zmianach wchodzących razem z wydaniem — pozwala zebrać je w spójną całość.
• Grupuj powiązane modyfikacje wspólnym numerem NRIDREV zamiast zapisywać je jako niezależne wpisy.
• Zestawiaj dziennik z tabelą _dbup przy diagnozie różnic między środowiskami — pierwsza opisuje zamiar, druga wykonanie.
• Rozważ założenie klucza głównego i indeksu na kolumnie KIEDY przy instalacjach utrzymywanych od lat.

Zmiany wdrożeniowe z ostatniego półrocza — te, które wymagają zabezpieczenia przed aktualizacją systemu:

SELECT  DATA_ZMIAN,
        KIEDY,
        LOGIN,
        ROLA,
        WERSJA,
        NRIDREV,
        LEFT(OPIS, 250) AS OPIS_ZMIANY
FROM    dbo._revision_sql
WHERE   CUSTOM = 1
  AND   ISNULL(DATA_ZMIAN, KIEDY) >= DATEADD(MONTH, -6, GETDATE())
ORDER BY NRIDREV DESC, KIEDY DESC;

Funkcja ISNULL jest tu potrzebna, bo kolumna daty zmiany dopuszcza wartość pustą — przy wpisach uzupełnianych po fakcie bywa niewypełniona.

Warto też ustalić, kto ten dziennik prowadzi. W praktyce wpisy powstają wtedy, gdy zmianę wprowadza osoba przyzwyczajona do dokumentowania swojej pracy — i znikają, gdy robi to ktoś inny. Dziennik uzupełniany wybiórczo jest gorszy niż jego brak, bo tworzy złudzenie kompletności: skoro nie ma wpisu, znaczy że nic nie zmieniano, a to nieprawda. Rozwiązaniem jest włączenie wpisu do procedury wdrażania zmiany, na równi z jej przetestowaniem.

Dziennik zmian systemowych jest tak przydatny, jak staranne są jego opisy. Wpis „poprawki” zapisany dwa lata temu nie pomoże nikomu; jedno zdanie mówiące, co i po co zmieniono, potrafi zaoszczędzić dnia pracy przy diagnozie różnicy między dwoma wdrożeniami.

Powiązane tabele i dokumentacja

Dziennik zmian systemowych czyta się razem z pozostałymi zapisami dotyczącymi wersji i konfiguracji: