SQL Server w logistyce

Tabela _edit w bazie danych SQL Server

Rejestr rekordów aktualnie edytowanych — zapobiega sytuacji, w której dwie osoby nadpisują nawzajem swoje zmiany.

sql.server.net.pl/sql/
Uśmiechnięty analityk w garniturze przy szerokim monitorze
Uśmiechnięty analityk w garniturze przy szerokim monitorze
W skrócie
  • Tabela pełni funkcję znacznika trwającej edycji: obecność wiersza oznacza, że ktoś właśnie pracuje na danym rekordzie.
  • Klucz główny na kolumnie REFNO gwarantuje, że jeden dokument nie może zostać zajęty przez dwie osoby jednocześnie.
  • Kolumny LOGIN i KIEDY pozwalają pokazać użytkownikowi, kto blokuje dokument i od jak dawna.
  • Wpisy osierocone po zerwaniu sesji trzeba usuwać cyklicznie — inaczej dokument pozostaje niedostępny mimo braku realnej edycji.

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

Gdy dwie osoby otworzą ten sam dokument i obie zapiszą zmiany, wygrywa ta, która kliknęła później — a praca pierwszej znika bez śladu i bez ostrzeżenia. Tabela [dbo].[_edit] zapobiega temu w najprostszy możliwy sposób: zapisuje, że dany rekord jest w tej chwili edytowany.

Mechanizm opiera się na kluczu głównym. Przy otwarciu dokumentu do edycji system próbuje dopisać wiersz z numerem referencyjnym rekordu. Jeżeli wiersz już istnieje, wstawienie się nie powiedzie i użytkownik zobaczy komunikat, że dokument jest zajęty. Po zapisaniu lub porzuceniu zmian wiersz jest usuwany, a rekord wraca do dyspozycji.

To rozwiązanie z rodziny blokad pesymistycznych — konflikt jest wykluczany, zanim powstanie, a nie wykrywany po fakcie. Jego zaletą jest przewidywalność: użytkownik dowiaduje się o zajętości przed rozpoczęciem pracy, nie po jej wykonaniu. Wadą — zależność od tego, czy blokada zostanie poprawnie zwolniona.

Cykl życia blokady edycyjnej
Otwarcie OtwarcieSystem próbuje dopisać wiersz z numerem REFNO dokumentu
Zajęcie ZajęcieUdany zapis oznacza wyłączność — inni zobaczą komunikat o blokadzie
Praca PracaKolumna KIEDY pozwala pokazać, od jak dawna trwa edycja
Zwolnienie ZwolnienieZapis lub rezygnacja usuwa wiersz i odblokowuje dokument

Kluczowy jest ostatni krok. Zerwana sesja nie usuwa wiersza, dlatego system potrzebuje mechanizmu sprzątającego wpisy pozostawione bez zamknięcia.

Budowa tabeli — wykaz kolumn

Cała informacja mieści się w trzech kolumnach — identyfikatorze blokowanego rekordu oraz danych o tym, kto i kiedy blokadę założył.

Wykaz kolumn tabeli
KolumnaTypWymaganaZnaczenie
KIEDYdatetime
data i godzina
nieData i czas dodania rekordu - rozpoczęcie edycji
LOGINvarchar(50)
tekst do 50 znaków
nieNazwa użytkownika kotry edytuje oryginaly zapis
REFNObigint
liczba całkowita 64-bitowa
takIdentyfikator wiersza tabeli, odnosi sie do edycji dokumentu oryginalnego np refno, nridodn itp

Kolumna REFNO przechowuje numer referencyjny rekordu z tabeli źródłowej. Ta sama wartość identyfikuje dokument w dzienniku zdarzeń i w rejestrze błędów, co pozwala powiązać blokadę z historią operacji.

Indeksy i wydajność zapytań

Tabela jest mała i odczytywana punktowo, ale jej indeks pełni rolę wykraczającą poza wydajność.

Indeksy zdefiniowane na tabeli
IndeksKolumnyRodzaj
PK__editREFNOklucz główny

Klucz główny na kolumnie REFNO nie służy tu przyspieszeniu odczytu, lecz wymuszeniu reguły biznesowej: jeden rekord może mieć najwyżej jedną blokadę. Ochrona przed równoczesną edycją opiera się na tym ograniczeniu, a nie na sprawdzeniu w kodzie aplikacji — dzięki czemu działa także wtedy, gdy dwa zgłoszenia trafią do serwera w tej samej chwili.

Blokada pesymistyczna a wykrywanie konfliktu — dwa podejścia

Ochrona przed nadpisaniem zmian daje się rozwiązać na dwa sposoby, które różnią się momentem wykrycia konfliktu. StudioSystem stosuje pierwszy z nich dla dokumentów edytowanych długo i przez wiele osób.

Porównanie sposobów ochrony przed równoczesną edycją
CechaBlokada zakładana z góry (tabela _edit)Wykrywanie konfliktu przy zapisie
Kiedy użytkownik dowiaduje się o konflikciePrzed rozpoczęciem pracyDopiero przy próbie zapisania zmian
Ryzyko utraty pracyBrak — drugi użytkownik w ogóle nie zaczynaRealne, jeśli zmian nie da się scalić
Zachowanie przy zerwanej sesjiBlokada zostaje, wymaga sprzątaniaBez konsekwencji
Obciążenie bazyDodatkowy zapis przy każdym otwarciuPorównanie znacznika wersji przy zapisie
Sprawdza się przyDługiej edycji dokumentów przez wiele osóbKrótkich, punktowych zmianach pojedynczych pól

Kolumna STAMP typu timestamp, obecna w większości tabel StudioSystem, umożliwia zastosowanie drugiego podejścia tam, gdzie blokada byłaby zbyt uciążliwa.

Wybór nie jest przypadkowy. Dokument magazynowy z kilkudziesięcioma pozycjami wypełnia się kilkanaście minut i scalenie równoległych zmian nie miałoby sensu — tu blokada jest właściwa. Zmiana jednego pola w kartotece towaru trwa sekundy, a blokowanie całej kartoteki na ten czas utrudniałoby pracę bez realnej korzyści.

Jak korzystać z tabeli w praktyce

Przy utrzymaniu systemu z blokadami edycyjnymi liczą się przede wszystkim dwie rzeczy: czytelny komunikat dla użytkownika i sprzątanie wpisów osieroconych.

  • Pokazuj w komunikacie o blokadzie wartość z kolumny LOGIN — informacja „dokument edytuje Jan Kowalski” pozwala rozwiązać sprawę rozmową zamiast zgłoszeniem do administratora.
  • Uruchamiaj cyklicznie zadanie usuwające wpisy starsze niż ustalony próg, na przykład kilka godzin; to jedyna ochrona przed blokadami po zerwanych sesjach.
  • Dobierz próg do najdłuższej realnej edycji w firmie — zbyt krótki spowoduje zdejmowanie blokad osobom, które nadal pracują.
  • Przy ręcznym usuwaniu blokady sprawdź w dzienniku zdarzeń, czy użytkownik faktycznie zakończył pracę; przedwczesne zwolnienie przywraca ryzyko, przed którym mechanizm ma chronić.
  • Nie zakładaj blokad na kartoteki edytowane punktowo — dla nich lepiej sprawdza się porównanie znacznika STAMP przy zapisie.
  • Monitoruj liczbę wierszy w tabeli; stały wzrost oznacza, że blokady nie są zwalniane i mechanizm sprzątający nie działa.

Zapytanie wskazujące blokady utrzymujące się nietypowo długo — kandydatów do sprawdzenia i ewentualnego zwolnienia:

SELECT  REFNO,
        LOGIN,
        KIEDY,
        DATEDIFF(MINUTE, KIEDY, GETDATE()) AS MINUT_TEMU
FROM    dbo._edit
WHERE   KIEDY < DATEADD(HOUR, -2, GETDATE())
ORDER BY KIEDY;

Przed usunięciem wierszy zwróconych przez to zapytanie warto sprawdzić w tabeli _sessionlog, czy sesje tych użytkowników są nadal aktywne.

Blokada edycyjna to mechanizm, którego użytkownicy nie zauważają, dopóki działa poprawnie. Zauważają go natychmiast, gdy zostaje wpis po awarii sieci, a dokument staje się niedostępny bez wyraźnego powodu — dlatego zadanie sprzątające jest tu równie ważne jak sama blokada.

Powiązane tabele i dokumentacja

Blokady edycyjne współpracują z rejestrami sesji i zdarzeń, które pozwalają ustalić, co działo się z dokumentem:

FAQ

Najczęściej zadawane pytania o tabelę _edit

01

Dlaczego dokument jest zablokowany, mimo że nikt go nie edytuje?

Najczęściej dlatego, że sesja użytkownika została przerwana — przez zamknięcie przeglądarki, utratę połączenia albo restart komputera — zanim system zdążył usunąć wiersz blokady. Wpis pozostaje w tabeli i blokuje dokument do czasu jego usunięcia. Rozwiązaniem jest cykliczne zadanie czyszczące wpisy starsze niż ustalony próg.

02

Jak bezpiecznie zdjąć blokadę ręcznie?

Przed usunięciem wiersza warto sprawdzić w rejestrze sesji, czy użytkownik wskazany w kolumnie LOGIN jest nadal zalogowany. Jeżeli tak, lepiej wyjaśnić sprawę bezpośrednio z nim — zdjęcie blokady osobie, która faktycznie pracuje, przywraca ryzyko nadpisania jej zmian.

03

Czy klucz główny na REFNO jest potrzebny ze względu na wydajność?

Nie tylko. Jego zasadnicza rola to wymuszenie reguły, że jeden rekord może mieć najwyżej jedną blokadę. Ograniczenie działa po stronie serwera bazy, więc chroni także wtedy, gdy dwa żądania otwarcia dokumentu dotrą w tej samej chwili — sprawdzenie w kodzie aplikacji mogłoby wtedy zawieść.

04

Kiedy zamiast blokady lepiej użyć kolumny STAMP?

Przy krótkich zmianach pojedynczych pól, na przykład w kartotekach. Kolumna timestamp zmienia wartość przy każdym zapisie, więc porównanie jej przy aktualizacji wykrywa, że ktoś zmodyfikował rekord w międzyczasie. Konflikt jest wykrywany później, ale nie ma ryzyka pozostawienia blokady po zerwanej sesji.

Słownik pojęć

Słownik pojęć

Pojęcia opisujące ochronę danych przed równoczesną edycją.

BBlokada pesymistyczna
Zajęcie rekordu na czas edycji, uniemożliwiające innym rozpoczęcie pracy nad nim. Wyklucza konflikt z góry, kosztem konieczności zwalniania blokady.
NNumer referencyjny (REFNO)
Identyfikator wiążący rekord z zapisami w rejestrach pomocniczych StudioSystem — blokadami, dziennikiem zdarzeń i rejestrem błędów.
WWpis osierocony
Blokada pozostawiona po sesji przerwanej awarią, której nikt nie zwolnił. Wymaga cyklicznego usuwania na podstawie czasu założenia.
MMicrosoft SQL Server
Serwer relacyjnej bazy danych, na którym pracują aplikacje SoftwareStudio. Odpowiada za spójność danych, uprawnienia dostępu, kopie zapasowe i wydajność zapytań.
IIndeks bazodanowy
Struktura przyspieszająca wyszukiwanie wierszy w tabeli. Dobrze dobrane indeksy skracają czas zapytań, ale spowalniają zapisy i zajmują miejsce na dysku.
RRole i uprawnienia
Mechanizm przypisywania użytkownikom dostępu do funkcji i danych. Zamiast nadawać uprawnienia pojedynczo, przypisuje się je do roli odpowiadającej stanowisku.
ŚŚlad rewizyjny
Nieusuwalny zapis, kto i kiedy zmienił dane w systemie. Podstawa wiarygodności ewidencji podczas audytu i kontroli.
WWydajność zapytań
Czas, w jakim baza danych zwraca wynik. Zależy od indeksów, planu wykonania i objętości przetwarzanych danych.

Zobacz to w praktyce

Sprawdź, jak systemy SoftwareStudio oparte na MS SQL Server wspierają ten obszar Twojej firmy.