- Wiersz opisuje zmianę jednego pola — z wartością sprzed edycji i po niej.
- Numer
NRIDREVspina pola zmienione w ramach jednej operacji, więc da się odtworzyć całą edycję. - Kolumny
TABELA,REVCOLUMNiREFNOwskazują, czego dokładnie dotyczyła zmiana. - Kolumna
OPISmieści powód edycji — jedyne pole w całym systemie odpowiadające na pytanie „dlaczego”.
Do czego służy tabela [dbo].[_revision]
Dziennik zdarzeń mówi, że dokument został zmieniony. Tabela [dbo].[_revision] mówi, co dokładnie się w nim zmieniło: która kolumna, jaka była wartość wcześniej i jaka jest teraz. To poziom szczegółowości potrzebny wtedy, gdy sam fakt edycji nie wystarcza — przy reklamacji, kontroli albo sporze o zawartość dokumentu.
Zapis jest prowadzony w rozbiciu na pojedyncze pola. Edycja dokumentu, w której zmieniono trzy wartości, tworzy trzy wiersze — połączone wspólnym numerem rewizji w kolumnie NRIDREV. Dzięki temu da się zarówno prześledzić losy jednego pola w czasie, jak i odtworzyć całą operację jako spójną całość.
Osobno warto zwrócić uwagę na dwie kolumny opisowe. CAPTION przechowuje etykietę pola widoczną na formularzu, więc raport nie musi tłumaczyć nazw technicznych na zrozumiałe. OPIS mieści powód edycji podawany przez użytkownika — pole, którego zwykle brakuje w systemach rejestrujących zmiany, a które najbardziej przydaje się przy analizie po czasie.
Numer rewizji spina wszystkie pola zmienione w jednej operacji — bez niego widać osobne zmiany, ale nie widać edycji jako całości.
Budowa tabeli — wykaz kolumn
Dwanaście kolumn dzieli się na wskazanie przedmiotu zmiany, jej treść oraz okoliczności.
| Kolumna | Typ | Wymagana | Znaczenie |
|---|---|---|---|
| Przedmiot zmiany | |||
BAZA | varchar(50) tekst do 50 znaków | tak | Nazwa bazy danych, tabeli ktroa jest poddawana rewizji, domyślnie softwarestudioConnectionString lub customConnectionString |
TABELA | varchar(50) tekst do 50 znaków | tak | Nazwa tabeli poddanej rewizji |
REVCOLUMN | varchar(50) tekst do 50 znaków | tak | Nazwa kolumny, w której została zmienina wartość - kolumna poddana rewizji |
REFNO | bigint liczba całkowita 64-bitowa | tak | Identyfikator rekordu tabeli poddawanej rewizji np. NRID.., REFNO, REFNO_POZ |
CAPTION | varchar(100) tekst do 100 znaków | nie | Etykieta pola wyświetlana na formularzy, opis kontrolki |
| Treść zmiany | |||
OVALUE | varchar(max) tekst bez limitu długości | tak | Dotychczasowa wartość pola (old value) |
NVALUE | varchar(max) tekst bez limitu długości | tak | Nowa wartość pola (new value) |
| Okoliczności | |||
ID_REVISION | int liczba całkowita | tak | Identyfikator wiersza tabeli |
NRIDREV | bigint liczba całkowita 64-bitowa | tak | Unikalny numer rewizji, łączy poszczególne zapisy danej rewizji |
KIEDY | datetime data i godzina | tak | data i czas wykonania rewizji |
LOGIN | varchar(50) tekst do 50 znaków | tak | Login użytkownika, który wykonał zmian w zapisie |
OPIS | varchar(max) tekst bez limitu długości | nie | Opis przyczyny dla której edytowano rekord, opconalnie zapisywane, gdy w x_skorowidz dla danej rewizji ustawiono parametr na DOMYSLNE=True |
Kolumny OVALUE i NVALUE mają typ varchar(max) i są oznaczone jako wymagane. Wartość pusta jest więc zapisywana jako pusty ciąg, nie jako brak wartości — o czym trzeba pamiętać przy porównywaniu.
Indeksy i wydajność zapytań
Trzy indeksy odpowiadają dwóm sposobom czytania historii: śledzeniu jednego rekordu oraz odtwarzaniu pojedynczej operacji.
| Indeks | Kolumny | Rodzaj |
|---|---|---|
PK__revision | ID_REVISION | klucz główny |
REFNO | REFNO | zwykły |
REFNO_NRIDREV | REFNO, NRIDREV | zwykły |
Indeks złożony REFNO_NRIDREV obsługuje najczęstszy scenariusz — pobranie historii rekordu z pogrupowaniem po operacjach. Osobny indeks na samym REFNO przydaje się, gdy interesują nas wszystkie zmiany bez rozbicia na rewizje.
Trzy poziomy szczegółowości zapisu zmian
StudioSystem prowadzi zapis zmian na trzech poziomach, które odpowiadają na coraz bardziej szczegółowe pytania. Dobór właściwego zależy od tego, czego się szuka.
| Poziom | Tabela | Odpowiada na pytanie |
|---|---|---|
| Operacja w systemie | _dziennik | Kto, kiedy i skąd wykonał jakąś operację |
| Zdarzenie na dokumencie | _historia | Co działo się z tym konkretnym dokumentem |
| Zmiana pojedynczego pola | _revision | Jaka wartość była wcześniej, a jaka jest teraz |
Wszystkie trzy wiąże numer referencyjny REFNO, więc przejście między poziomami nie wymaga dopasowywania po czasie i loginie.
Rozdzielenie ma też uzasadnienie praktyczne. Zapis na poziomie pola jest najbardziej kosztowny — jedna edycja formularza z dziesięcioma polami tworzy dziesięć wierszy. Gdyby prowadzić go dla wszystkich tabel w systemie, rejestr rewizji przewyższyłby objętością dane operacyjne. Stąd kolumna TABELA: mechanizm włącza się wybiórczo, dla struktur, w których szczegółowość jest naprawdę potrzebna.
Jak korzystać z tabeli w praktyce
Przy korzystaniu z rejestru rewizji sprawdzają się poniższe zasady:
- Grupuj wyniki po
NRIDREV, gdy chcesz zobaczyć edycję jako całość, a nie ciąg niepowiązanych zmian pól. - Pokazuj w raportach wartość z kolumny
CAPTIONzamiast nazwy technicznej kolumny — użytkownik rozpozna pole z formularza. - Wymuszaj wypełnienie kolumny
OPISprzy edycji dokumentów o znaczeniu rozliczeniowym; bez powodu sama zmiana niewiele wyjaśnia. - Włączaj rejestrowanie wybiórczo, dla tabel faktycznie tego wymagających — koszt rośnie z liczbą zmienianych pól, nie dokumentów.
- Pamiętaj, że wartość pusta zapisywana jest jako pusty ciąg; porównanie z wartością nieustaloną wymaga uwzględnienia obu przypadków.
- Archiwizuj starsze rewizje osobno od danych operacyjnych — ten rejestr rośnie najszybciej ze wszystkich.
Pełna historia zmian wskazanego rekordu, pogrupowana po operacjach:
SELECT r.NRIDREV,
r.KIEDY,
r.LOGIN,
ISNULL(r.CAPTION, r.REVCOLUMN) AS POLE,
LEFT(r.OVALUE, 100) AS BYLO,
LEFT(r.NVALUE, 100) AS JEST,
LEFT(r.OPIS, 150) AS POWOD
FROM dbo._revision AS r
WHERE r.REFNO = @refno
AND r.TABELA = @tabela
ORDER BY r.NRIDREV, r.REVCOLUMN;
Sortowanie po numerze rewizji, a nie po czasie, sprawia, że pola zmienione w jednej operacji pozostają razem — nawet jeśli zapis trwał kilka sekund.
Rejestr zmian na poziomie pola jest najdroższym rodzajem zapisu i najbardziej wartościowym, gdy trzeba wykazać, jak wyglądał dokument w konkretnym momencie. Właściwa decyzja przy wdrożeniu nie brzmi „włączyć czy nie”, tylko „dla których tabel”.
Powiązane tabele i dokumentacja
Rejestr rewizji stanowi najniższy poziom zapisu zmian; pozostałe opisują poniższe tabele: