Wyzwalacze SQL oraz kiedy i kiedy nie należy ich używać.

Kiedy początkowo uczyłem się o SQL, zawsze mi mówiono, że używaj wyzwalaczy tylko wtedy, gdy naprawdę potrzebujesz, i zamiast tego wybieraj procedury przechowywane, jeśli to możliwe.

Niestety, w tamtym czasie (kilka dobrych lat temu) nie byłem tak ciekawy i dbałem o podstawy jak teraz, więc nigdy nie pytałem o powód.

Jaka jest w tym opinia społeczności? Czy to tylko czyjeś osobiste preferencje, czy też należy unikać wyzwalaczy (tak jak kursory), chyba że istnieje ku temu dobry powód.

Artykuł w Wikipedii na temat wyzwalaczy baz danych przedstawia dobry przegląd wyzwalaczy i kiedy ich używać w różnych bazach danych.

Poniższa dyskusja oparta jest tylko na SQL Server.

Używanie wyzwalaczy jest całkiem prawidłowe, gdy ich użycie jest uzasadnione. Na przykład mają dobrą wartość w inspekcji (prowadzenie historii danych) bez wymagania jawnego kodu proceduralnego dla każdej komendy CRUD w każdej tabeli.

Wyzwalacze zapewniają kontrolę tuż przed zmianą danych i tuż po zmianie danych. Pozwala to na:

• Audyt jak wspomniano wcześniej
• Sprawdzanie poprawności i sprawdzanie bezpieczeństwa biznesowego, jeśli jest to pożądane. Z powodu tego rodzaju kontroli można wykonywać zadania, takie jak formatowanie kolumn przed wstawieniem do bazy danych i po nim.

Zawsze mi mówiono, że używaj wyzwalaczy tylko wtedy, gdy naprawdę potrzebujesz i zamiast tego wybieraj procedury przechowywane, jeśli to możliwe.

Mogą to być niektóre z następujących przyczyn:

1. Niektóre funkcje, które kiedyś były uruchamiane, można teraz wykonywać na inne sposoby, takie jak aktualizacja sum i automatyczne obliczanie w kolumnie.
2. Nie widzisz, gdzie wywoływany jest wyzwalacz, badając sam kod, nie wiedząc, że istnieje. Widzisz ich efekt, gdy widzisz zmiany danych i czasem zastanawiasz się, dlaczego zmiana nastąpiła, chyba że wiesz, że na stole (stołach) występuje wyzwalacz lub więcej.
3. Jeśli używasz kilku elementów sterujących bazy danych, takich jak SPRAWDŹ, RI, Wyzwalacze w kilku tabelach, szczegółowy przepływ transakcji staje się skomplikowany do zrozumienia i utrzymania. Musisz dokładnie wiedzieć, co się stanie, kiedy. Ponownie będziesz potrzebować dobrej dokumentacji do tego.

Niektóre różnice między wyzwalaczami a procedurami przechowywanymi bez wyzwalacza to (między innymi):

• Nie przechowywana procedura przechowywana jest jak program, który musi być wywoływany jawnie albo z kodu, albo z harmonogramu, albo z zadania wsadowego itp., Aby wykonać swoją pracę, podczas gdy wyzwalacz jest specjalnym rodzajem procedury przechowywanej, która jest uruchamiana jako reakcja na zdarzenie, a nie wykonywana bezpośrednio przez użytkownika. Zdarzeniem może być na przykład zmiana danych w kolumnie danych.
• Wyzwalacze mają typy. Wyzwalacze DDL i Wyzwalacze DML (typów: INSTEAD OF, For i AFTER)
• Procedury przechowywane bez wyzwalania mogą odwoływać się do dowolnego typu obiektu, jednak aby odwołać się do widoku, należy użyć wyzwalaczy INSTEAD OF.
• W SQLServer możesz mieć dowolną liczbę procedur przechowywanych bez wyzwalacza, ale tylko 1 INSTEAD z wyzwalacza na tabelę.

Wyzwalacze są wymagane dla wszelkich złożonych reguł integralności danych. Nie można ich egzekwować nigdzie poza bazą danych, w przeciwnym razie wystąpią problemy z integralnością danych.

Są również najlepszym miejscem do przeprowadzania inspekcji, chyba że nie chcesz przechwytywać wszystkich zmian w bazie danych (co jest problemem podczas inspekcji z aplikacji).

Wyzwalacze mogą powodować problemy z wydajnością, jeśli nie zostaną napisane starannie, a niewystarczająca liczba programistów jest wystarczająco kompetentna, aby je dobrze napisać. To część ich złego rapu.

Wyzwalacze są często wolniejsze niż inne sposoby zachowania integralności danych, więc jeśli możesz użyć ograniczenia sprawdzania, użyj tego zamiast wyzwalacza.

Łatwo jest pisać złe wyzwalacze, które robią głupie rzeczy, takie jak próba wysyłania e-maili. Czy naprawdę chcesz nie być w stanie zmienić rekordów w bazie danych, jeśli serwer e-mail ulegnie awarii?

W SQL Server wyzwalacze działają na partii rekordów. Zbyt często programiści uważają, że muszą obsłużyć tylko jedną wstawkę, aktualizację lub usunięcie jednego rekordu. To nie jedyny rodzaj zmian danych, które mają miejsce w bazie danych i wszystkie wyzwalacze powinny być testowane w warunkach 1 zmiany rekordu i wielu zmian rekordu. Zapomnienie o zrobieniu drugiego testu może prowadzić do wyjątkowo słabo działających wyzwalaczy lub utraty integralności danych.

Korzystanie z wyzwalaczy bazy danych

1. Aby automatycznie sterować wartościami kolumn.
2. Aby wymusić złożone ograniczenia integralności.
3. Aby egzekwować złożone reguły biznesowe.
4. Aby dostosować złożone autoryzacje bezpieczeństwa.
5. Aby zachować replikowane tabele.
6. Aby przeprowadzić audyt modyfikacji danych.

Innym przypadkiem użycia, z którym osobiście się spotkałem, są bazy danych, do których dostęp ma więcej niż jeden program. Jeśli chcesz wdrożyć funkcjonalność, ale nie przeprojektować dla niej wszystkie systemy, wyzwalacz stanowi sensowne rozwiązanie.

Na przykład ostatnio pracowałem nad bazą danych, która wcześniej istniała wyłącznie jako system biurowy. Kiedy aplikacja WWW została napisana do współpracy z nią, chcieliśmy wdrożyć system powiadomień (na przykład podobny do wymiany stosów), który byłby uruchamiany przez wiele zdarzeń, takich jak przetwarzanie transakcji i tak dalej. Byliśmy w stanie zaimplementować wyzwalacz, dzięki czemu aktualizacje w zapleczu biurowym uruchomiły wyzwalacz, aby utworzyć powiadomienie dla interfejsu użytkownika i poinformować użytkownika, że ​​jego transakcja została przetworzona przez biuro.

Wyzwalaczy można używać do wymuszania ograniczeń w bazie danych, których nie można egzekwować podczas tworzenia schematu bazy danych ani żadnych instrukcji DML.

Powiedzmy, że musisz przekazywać dane do systemu innej firmy w czasie zbliżonym do rzeczywistego. Twój stół zawiera 950 gigabajtów danych, więc jest zbyt duży, aby po prostu zepchnąć cały stół do aplikacji innej firmy.

Zamiast tego kumulujesz zmiany w kolejce. Niektóre programy zewnętrzne będą następnie okresowo wypychać małe partie danych w kolejce.

System ma ponad 2000 procedur przechowywanych. Wiesz także, że w kodzie źródłowym istnieje mnóstwo sql. Aby upewnić się, że kolejka jest poprawnie zapełniona, musisz przeszukać wszystkie zapisane procesy i kod i mieć nadzieję, że niczego nie przeoczysz.

Zamiast tego możesz umieścić wyzwalacz na stole, aby aktualizować kolejkę. Gwarantujemy, że niczego nie przegapisz. Jedna centralna lokalizacja. Kara za wydajność? Nie do końca, ponieważ nie można uniknąć trafienia zapełniania kolejki, czy to przez wyzwalacz, czy na zewnątrz.

W tym scenariuszu powiedziałbym, że niestosowanie wyzwalacza jest złym wyborem projektu. Jeśli później chcesz użyć nowej metody wypychania danych (powiedzmy, że kolejka nie działa), a interfejs zmienia się, jesteś chroniony, jeśli użyjesz wyzwalacza. Wyzwalacze są często najlepszym wyborem. Nie słuchaj dogmatycznych fanboyów anty-spustowych.

Wyzwalacz wysyłający e-mail niekoniecznie jest „głupim” pomysłem. Głupie jest to, że nie przewiduje się awarii e-maila w projekcie i radzi sobie z nim płynnie bez utraty danych. „Głupia” część tego naprawdę szkodzi nieistniejącej obsłudze błędów przez leniwych programistów, którzy uważają, że są odporni na popełnianie błędów.

Chciałbym również zwrócić uwagę na to, że wyzwalacz można uprościć, wywołując procedurę / funkcję przechowywaną, która może być dowolnie skomplikowana i może być wielokrotnie używana przez wiele wyzwalaczy lub innych procedur przechowywanych. Dlatego istnieją pakiety i biblioteki.

Bigoteria jest naprawdę paraliżująca.