Wyzwalacz UPDATE

Wyzwalacz UPDATE uruchamia się w reakcji na modyfikację istniejących wierszy tabeli.

Mechanika wyzwalacza reagującego na zmianę wiersza

Wyzwalacz UPDATE to procedura przypisana do tabeli, którą silnik bazy uruchamia automatycznie przy każdej instrukcji modyfikującej dane. W SQL Server tworzy się go składnią CREATE TRIGGER nazwa ON tabela AFTER UPDATE, a wewnątrz dostępne są dwie tabele wirtualne: deleted zawiera stan wierszy sprzed zmiany, inserted stan po zmianie. Ich połączenie po kluczu głównym daje pełny obraz tego, co się wydarzyło, i to jest podstawa każdego dziennika audytowego. Kluczowa rzecz, którą początkujący przeoczają: wyzwalacz odpala się raz na instrukcję, a nie raz na wiersz. Aktualizacja tysiąca rekordów jednym UPDATE-em wywoła go jeden raz, z tysiącem wierszy w tabeli inserted, więc kod pisany pod pojedynczy wiersz — z SELECT do zmiennej skalarnej — po cichu przetworzy tylko jeden z nich.

Wybór momentu i zakresu reakcji

AFTER UPDATE działa po wykonaniu zmiany i po sprawdzeniu więzów integralności; nadaje się do logowania, przeliczania sum kontrolnych i powiadamiania. INSTEAD OF UPDATE zastępuje oryginalną operację i jest jedynym sposobem na modyfikowalne widoki łączące kilka tabel. Do zawężenia reakcji służy funkcja UPDATE(nazwa_kolumny), zwracająca prawdę, gdy dana kolumna wystąpiła na liście SET — pozwala pominąć całą logikę, gdy zmieniono tylko datę modyfikacji. Uwaga na subtelność: UPDATE() zwraca prawdę także wtedy, gdy kolumnie przypisano tę samą wartość co poprzednio, więc realną zmianę trzeba porównać samodzielnie między inserted a deleted. W MySQL odpowiednikiem tabel wirtualnych są prefiksy OLD i NEW, a wyzwalacz z definicji pracuje wierszowo — przenosząc logikę między silnikami, trzeba przepisać ją od zera.

Gdzie to się wykłada w praktyce

Pierwszy klasyk to spowolnienie zapisu: wyzwalacz wykonuje się w tej samej transakcji co UPDATE, więc jego czas dopisuje się do czasu operacji i wydłuża blokady na tabeli. Ciężki zapis do tabeli dziennika bez indeksu potrafi zamienić szybką korektę cennika w kilkuminutową blokadę widoczną dla wszystkich użytkowników programu handlowego. Drugi problem to rekurencja: wyzwalacz aktualizujący własną tabelę uruchamia sam siebie, a przy włączonej opcji nested triggers łańcuch kończy się błędem o przekroczeniu 32 poziomów zagnieżdżenia. Trzeci to niewidzialność — wyzwalacz nie pojawia się w kodzie aplikacji, więc gdy dane zmieniają się same, nikt nie wie dlaczego, dopóki ktoś nie przejrzy sekcji Triggers w drzewie tabeli. Czwarty: instrukcje masowe potrafią wyzwalacz ominąć, jeśli ładowanie odbywa się z pominięciem logiki tabeli.

Serwis przy bazach programów handlowych

Bazy Subiekta, WAPRO i Comarch osadzone na SQL Server bywają rozbudowywane własnymi wyzwalaczami — dopisującymi do dziennika, synchronizującymi ze sklepem internetowym, pilnującymi stanów magazynowych. Po aktualizacji wersji programu takie dodatki potrafią przestać pasować do zmienionej struktury tabel i objawiają się błędem przy zapisie dokumentu. Zajmujemy się wdrażaniem i serwisowaniem tego oprogramowania, więc analiza planu wykonania, sprawdzenie blokad i przepisanie wyzwalacza na pracę zbiorczą mieszczą się w zakresie naszej pracy. Diagnozę można zacząć zdalnie o dowolnej porze — obsługujemy zgłoszenia całodobowo, także w weekendy, gdy najłatwiej zrobić przerwę w pracy magazynu.