Czy baza danych wyzwala zło? [Zamknięte]


186

Czy baza danych wyzwala zły pomysł?

Z mojego doświadczenia wynika, że ​​są złe, ponieważ mogą wywoływać zaskakujące skutki uboczne i są trudne do debugowania (szczególnie, gdy jeden spust uruchamia inny). Często programiści nawet nie myślą o tym, czy jest jakiś czynnik uruchamiający.

Z drugiej strony wydaje się, że jeśli masz logikę, która musi wystąpić za każdym razem, FOOw bazie danych tworzony jest nowy, wówczas najbardziej niezawodnym miejscem na umieszczenie go jest wyzwalacz wstawiania w tabeli FOO.

Jedyny raz, kiedy używamy wyzwalaczy, to naprawdę proste rzeczy, takie jak ustawienie ModifiedDate.


31
To jest całkowicie uzasadnione pytanie, ale nie podoba mi się sensacyjny tytuł. Myślę coś w rodzaju „Jakie są najważniejsze kwestie do rozważenia przy wdrażaniu wyzwalaczy baz danych?” byłoby znacznie lepiej.
Tamas Czinege

2
Pytanie jest zamknięte, aby dodać odpowiedzi, ale zobacz także Czy wyzwalacze bazy danych są bezpieczne dla ograniczeń integralności między tabelami? . (Spoiler: nie, nie są)
Mifeet

16
Ta strona bardzo mnie wkurza. To jest WIELKIE pytanie, ale jak wiele innych jest zamknięte, ponieważ ludzie nie mają wyobraźni, aby zaakceptować pytania, które nie pasują do prymitywnego binarnego formatu pytań i odpowiedzi, które z jakiegoś obcego powodu czują się zmuszone do naśladowania.
Quibblesome

1
Logika biznesowa w wyzwalaczu jest problematyczna (zło, jeśli wolisz). Logika bazy danych w wyzwalaczu nie stanowi problemu (integralność, rejestrowanie).
Greg Gum

1
Lubię polegać na IDE do nawigacji kodu i rozumienia, co się dzieje. Nie mogę tego zrobić, jeśli połowa logiki znajduje się w bazie danych, a druga połowa w wybranym języku programowania. Zamiast wyzwalaczy łatwiej jest mi stworzyć kontroler, przez który musi przejść każde żądanie. Zamiast tego można zastosować wszystkie „wyzwalacze”.
Muhammad Umer

Odpowiedzi:


147

Główne problemy z wyzwalaczami to

  • Są całkowicie globalne - mają zastosowanie bez względu na kontekst działania tabeli;
  • Są niewidzialni; łatwo jest zapomnieć, że są tam, dopóki cię nie skrzywdzą z niezamierzonymi (i bardzo tajemniczymi) konsekwencjami.

Oznacza to po prostu, że należy je ostrożnie stosować w odpowiednich okolicznościach; które z mojego doświadczenia ogranicza się do problemów związanych z integralnością relacyjną (czasami o większej szczegółowości, niż można uzyskać deklaratywnie); i zwykle nie w celach biznesowych lub transakcyjnych. YMMV.


20
W niektórych przypadkach są to 2 zalety.
Johnno Nolan

18
„Stealthy” to świetne słowo, tak - dobrze powiedziane. Właśnie dlatego mam tendencję do unikania ich: zbyt często są zapominani lub ignorowani. Z mojego osobistego doświadczenia, ponowne spojrzenie na wyzwalacze często towarzyszy mi uderzenie w czoło.
Christian Nunciato,

5
Globalny jest powodem, dla którego są one dobre i niezbędne do zapewnienia integralności danych i takich rzeczy jak audyt. To nie jest minus, to plus.
HLGEM

4
więc @ RobertŠevčík-Robajz, mówisz, że wszyscy programiści, których znasz, są niekompetentni?
HLGEM

3
@HGLEM, zgadzam się, że powinien istnieć specjalista do opracowania wyzwalaczy. Scenariusz z życia - nie ma. Scenariusz z życia - dni spędzone na próbach zidentyfikowania błędu związanego z zapomnianym wyzwalaczem. Scenariusz z życia - logika wyzwalania rozpaczliwie wypychana jest do logiki aplikacji, gdzie można ją łatwo refaktoryzować i testować jednostkowo. To prawdziwe życie, z którym mam do czynienia, sprawia, że ​​mówię „trzymaj się z dala od wyzwalaczy” ... to nie jest wina wyzwalaczy, ponieważ to nie wina, że ​​pękają okna.
Rbjz

80

Nie, to naprawdę dobry pomysł. Jeśli występuje problem z konkretnymi wyzwalaczami, oznacza to, że nie robisz ich dobrze, ale zwykle oznacza to problem z implementacją, a nie samą koncepcję wyzwalaczy :-).

Bardzo często używamy wyzwalaczy, ponieważ umieszcza działanie specyficzne dla DBMS pod kontrolą bazy danych, do której należy. Użytkownicy DBMS nie powinni się martwić o takie rzeczy. Integralność danych zależy od samej bazy danych, a nie od aplikacji lub użytkowników, którzy z niej korzystają. Bez ograniczeń, wyzwalaczy i innych funkcji w bazie danych, egzekwowanie reguł należy do aplikacji, a zniszczenie danych wymaga tylko jednej nieuczciwej lub błędnej aplikacji / użytkownika.

Na przykład bez wyzwalaczy takie cudowne rzeczy, jak automatycznie generowane kolumny, nie istniałyby, a przy ich wybieraniu trzeba byłoby przetwarzać funkcję w każdym wierszu. Prawdopodobnie zabije to wydajność DBMS, znacznie lepiej jest utworzyć kolumnę generowaną automatycznie w czasie wstawiania / aktualizacji, ponieważ jest to jedyny czas, w którym się zmienia.

Ponadto brak wyzwalaczy uniemożliwiłby wymuszanie reguł danych w DBMS, takich jak wstępne wyzwalacze, aby kolumny miały określony format. Zauważ, że różni się to od zasad integralności danych, które są zwykle po prostu wyszukiwaniem kluczy obcych.


9
msgstr "przetwarzaj funkcję w każdym rzędzie podczas ich wybierania". W tym celu lepiej jest użyć indeksu opartego na funkcjach niż wyzwalacza.
tuinstoel

10
Niekoniecznie wyzwalacz prawdopodobnie zadziała tylko wtedy, gdy wiersz zostanie wstawiony lub zaktualizowany. Indeks funkcyjny będzie uruchamiany dla każdego wyboru. W zależności od wzorca użytkowania jeden jest prawdopodobnie lepszy od drugiego. Ale żadna z nich ZAWSZE nie jest lepsza od drugiej.
jmucchiello,

@tuinstoel: Muszę zgodzić się z wyciągu jakiś czas. Na przykład Oracle utworzy indeksy oparte na funkcjach tylko wtedy, gdy może udowodnić, że funkcja jest deterministyczna. Czasami tego po prostu nie da się udowodnić (na przykład, jeśli funkcja obejmuje przeglądanie tabeli, nawet jeśli wiesz, że dane tabeli nigdy się nie zmieniają).
Adam Paynter

50

Narzędzia nigdy nie są złe. Zastosowania tych narzędzi mogą być złe.


11
Nigdy nie byłem bardziej skonfliktowany po przeczytaniu komentarza. Z jednej strony opowiadam się za drugą poprawką i wierzę, że pistolety nie są z natury złe: to osoba, która ich używa. Z drugiej strony, wierzę, że to wyzwala SĄ Złe ... Myślę, że mam egzystencjalne załamanie ...
vbullinger

37
Pistolety @vbullinger nie są złe, ale ich wyzwalacze są;)
Darragh Enright

2
: D Uogólnienia są niebezpieczne (rekurencyjnie). Czy przyszedłeś przez „narzędzia” tortur stosowane przez inkwizytorów do „sprowadzenia” spowiedzi? W każdym razie +1 dla perspektywy.
Rbjz

22

Zgadzam się. Problemy z wyzwalaczami to ludzie, a nie wyzwalacze. Chociaż jest to więcej do oglądania, więcej do rozważenia i zwiększa ciężar programistów sprawdzających wszystko poprawnie, nie odrzucamy indeksów, aby uprościć nam życie. (Złe indeksy mogą być tak samo złe jak złe wyzwalacze)

Znaczenie wyzwalaczy (moim zdaniem) polega na tym, że ...
- Każdy system powinien być zawsze w poprawnym stanie
- Kod wymuszający ten prawidłowy stan powinien być scentralizowany (nie zapisany w każdym SP)

Z punktu widzenia konserwacji, wyzwalacz jest bardzo przydatny dla konkurencyjnych programistów i problemów dla bardziej młodszych / amatorskich. Jednak ci ludzie muszą się jakoś uczyć i wzrastać.

Myślę, że sprowadza się to do twojego środowiska pracy. Czy masz wiarygodnych ludzi, którzy dobrze się uczą i którym można polegać na metodyce? Jeśli nie, najwyraźniej masz dwie możliwości:
- Zaakceptuj, że musisz utracić funkcjonalność, aby to zrekompensować
- Zaakceptuj, że potrzebujesz różnych ludzi lub lepszego szkolenia i zarządzania

Brzmią szorstko i chyba tak. Ale to podstawowa prawda, moim zdaniem ...


3
>>> Problemami z wyzwalaczami są ludzie. Tak, jeśli tylko ludzie mogliby kodować w asemblerze, pracować z kiepskim GUI, odgadnąć poprawnie, czy popchnąć lub pociągnąć źle zaprojektowane drzwi ... Każda „cecha”, w której ludzie często się mylą, jest „zła”.
Fakrudeen

1
@Frrudeen, każdy programista, który źle się uruchamia, nie jest w stanie uzyskać dostępu do bazy danych.
HLGEM,

20

Myślę, że wyzwalacze są nie tylko złe, ale są niezbędne do dobrego projektu bazy danych. Programiści aplikacji uważają, że na bazy danych ma wpływ tylko ich aplikacja. Często się mylą. Jeśli integralność danych ma być utrzymywana bez względu na to, skąd nastąpiła zmiana danych, wyzwalacze są wymaganiem i głupotą jest ich unikanie, ponieważ niektórzy programiści są zbyt etnocentryczni, aby uważać, że coś innego niż ich cenne zastosowanie może mieć wpływ na rzeczy. Nie jesteś trudny do zaprojektowania, przetestowania lub rozwiązania problemu z wyzwalaczem, jeśli jesteś kompetentnym programistą baz danych. Nie jest również trudne do ustalenia, że ​​wyzwalacz powoduje nieoczekiwany rezultat, jeśli przyjdzie ci (tak jak mnie) spojrzeć tam. Jeśli pojawia się błąd informujący, że tabela, do której nie odwołuję się w moim systemie operacyjnym, ma błąd FK, Wiem, nawet o tym nie myśląc, że przyczyną problemu jest wyzwalacz, a także każdy kompetentny programista baz danych. Umieszczanie reguł biznesowych tylko w aplikacji jest główną przyczyną, dla której znalazłem złe dane, ponieważ inni nie mają pojęcia, że ​​reguła w ogóle istnieje i narusza ją w swoich procesach. Reguły skoncentrowane na danych należą do bazy danych, a wyzwalacze są kluczem do egzekwowania bardziej złożonych.


Reguły zorientowane na dane należą do bazy danych
absin

miał mniesome programmers are too ethnocentric to consider that something other than their prized application may be affecting things
Kid101

13

W większości tak.

Trudność z wyzwalaczem polega na tym, że robi rzeczy „za twoimi plecami”; deweloper utrzymujący aplikację z łatwością nie zdawał sobie sprawy z jej obecności i wprowadzał zmiany, które psują wszystko, nawet nie zauważając.

Tworzy warstwę złożoności, która po prostu dodaje prace konserwacyjne.

Zamiast używać wyzwalacza, procedura / procedura składowana może być generalnie wykonana tak, aby robić to samo, ale w jasny i łatwy do utrzymania sposób - wywołanie procedury przechowywanej oznacza, że ​​programista może spojrzeć na kod źródłowy i zobaczyć dokładnie, co się dzieje.


12
Jest to zaleta wyzwalacza, a nie disadvatage! Nie można zagwarantować, że zapisane procy będą wywoływane przy każdej zmianie danych. Istnieje wiele sposobów zmiany danych oprócz GUI.
HLGEM

2
HLGEM, który zależy od twojej kontroli dostępu. Możesz odmówić jakiejkolwiek modyfikacji tabel bezpośrednio, z wyjątkiem procedury składowanej.
Rbjz

1
Myślę, że chodzi o to, że jeśli na przykład rekordy w dwóch tabelach ZAWSZE powinny być tworzone i niszczone razem, bez względu na to, jak uzyskujesz dostęp do bazy danych i bez względu na to, kim jesteś i jakie masz uprawnienia, wówczas wyzwalacze są jedynym uzasadnionym rozwiązaniem . Sam fakt, że jest to nawet możliwe , aby przypisać zbyt wiele lub niepoprawne uprawnienia i oczekiwać, aby ludzie wiedzieli, które przechowywane procedury mają być stosowane, oznacza, że baza danych jest na ryzyko utraty jego integralności. Jest dokładnie taki sam jak relacje klucza obcego. To po prostu NAJLEPSZE i NAJBARDZIEJ NIEZAWODNIE wymuszone przez silnik bazy danych.
Triynko

2
Jeśli rekordy powinny być zawsze tworzone / niszczone razem, utwórz ograniczenie sprawdzające, które zapewni, że są. W ten sposób ktoś, kto łamie zasady, otrzymuje błąd, a nie ukryte zachowanie, które magicznie naprawia wszystko bez ich wiedzy i zgody.
MarkR

9

Wyzwalacze są niezwykle potężne i przydatne, istnieje wiele scenariuszy, w których wyzwalacz jest najlepszym rozwiązaniem problemu.

Są również bardzo dobrym narzędziem „hackowania”. Często zdarza się, że nie masz bezpośredniej kontroli zarówno nad kodem, jak i bazą danych. Jeśli musisz poczekać 2 miesiące na następne główne wydanie kodu, ale możesz od razu zastosować poprawkę do bazy danych, możesz umieścić wyzwalacz na stole, aby wykonać dodatkowe funkcje. Następnie, gdy możliwe jest wydanie kodu, możesz w razie potrzeby zastąpić ten wyzwalacz zakodowaną wersją tej samej funkcji.

Ostatecznie wszystko jest „złe”, jeśli nie wiesz, co robi. Decyzja, że ​​wyzwalacze są spowodowane tym, że są programiści, którzy ich nie rozumieją, jest tym samym, co argumentowanie, że samochody są złe, ponieważ niektórzy ludzie nie mogą prowadzić ...


7

Wyzwalacze mają swoje zastosowania - logowanie / audyt i utrzymywanie daty „ostatniej modyfikacji” to dwa bardzo dobre zastosowania, o których wspomniano w poprzednich odpowiedziach.

Jednak jednym z podstawowych założeń dobrego projektu jest to, że reguły biznesowe / logika biznesowa / cokolwiek chcesz to nazwać, powinny być skoncentrowane w jednym miejscu. Umieszczenie części logiki w bazie danych (za pośrednictwem wyzwalaczy lub przechowywanych proc) i niektórych w aplikacji narusza tę zasadę. Powielanie logiki w obu miejscach jest jeszcze gorsze, ponieważ niezmiennie nie będą się ze sobą synchronizować.

Wspomniano już o zasadzie „najmniejszego zaskoczenia”.


3
Zgadza się, powinna znajdować się w jednym miejscu, w bazie danych. Logika, która wpływa na integralność danych, musi ZAWSZE znajdować się w bazie danych, a nigdy w aplikacji, w której mogłaby zostać wywołana w przypadku wpływu na dane w bazie danych.
HLGEM

1
@HLGEM: Zależy to od tego, czy baza danych może mieć dostęp do informacji, które pozwalają stwierdzić, czy dane są prawidłowe. Nie zawsze tak jest; gdy weryfikator jest w innej organizacji (np. w sprawie danych karty kredytowej lub rachunku bankowego), wówczas DB nie może wiedzieć, czy jest to poprawne - zakładając, że to nie DB banku! - i będzie musiał polegać na wniosku o wykonanie. Nie chcesz, aby baza danych tworzyła losowe połączenia z usługami stron trzecich, ponieważ jest to złe, jeśli chodzi o wdrażanie serwera.
Donal Fellows

@HLGEM: Chociaż nie jestem gotów całkowicie wykluczyć opcji umieszczenia całej logiki aplikacji w bazie danych, okazuje się, że lepiej jest umieścić ją w innym miejscu, ogólnie warstwę OO wielokrotnego użytku, której można używać we wszystkich aplikacjach uzyskujących dostęp baza danych. Tak długo, jak twoja aplikacja uzyskuje dostęp do bazy danych tylko przez warstwę obiektową, obowiązują te same gwarancje logiki, która zawsze jest wywoływana.
Dave Sherohman,

2
Nigdy nie pracowałem nad aplikacją biznesową, która wstawiała dane do bazy danych tylko przez warstwę Object, a ja nie chciałbym pracować nad jedną. Głupio jest wprowadzać milion importów lub aktualizacji wszystkich cen w procesie zaprojektowanym do obsługi tylko jednego rekordu jednocześnie. Warstwa obiektowa jest niewłaściwym miejscem do egzekwowania integralności danych, dlatego tak wiele baz danych ma problemy z integralnością.
HLGEM,

@HLGEM Z tego właśnie powodu pracuję nad rozszerzeniem naszego ORM, aby działał jak wyzwalacz przy użyciu zestawu zmian wszystkiego w ramach transakcji. Wydaje się to trochę głupie, ale uniemożliwi nam wykorzystanie całej naszej logiki biznesowej w aplikacji, z wyjątkiem kilku przypadków, gdy nie jest to możliwe (tylko kilka tabel wymaga aktualizacji zbiorczej). Umożliwi to również wszystkim programistom pisanie i używanie ich w języku, który najbardziej im odpowiada i gdzie jest dostęp do wszystkich abstrakcyjnych obiektów, które zbudowaliśmy.
Adamantish

6

Wyzwalacze są dobrym narzędziem, jeśli są właściwie używane. Zwłaszcza w przypadku kontroli zmian, wypełniania tabel podsumowań itp.

Teraz mogą być „złe”, jeśli skończysz w „wyzwalaniu piekła” z jednym wyzwalaczem, który uruchamia inne wyzwalacze. Kiedyś pracowałem nad produktem COTS, w którym mieli coś, co nazywali „Flex Trigger”. Te wyzwalacze były przechowywane w tabeli, ponieważ dynamiczne zapytania SQL są kompilowane za każdym razem, gdy są wykonywane. Skompilowane wyzwalacze sprawdzą w górę i sprawdzą, czy ta tabela ma jakieś wyzwalacze Flex do uruchomienia, a następnie skompilują i uruchomią wyzwalacz „flex”. Teoretycznie wyglądało to na naprawdę fajny pomysł, ponieważ produkt można łatwo dostosować, ale w rzeczywistości baza danych eksplodowała z powodu wszystkich kompilacji, które musiała wykonać ...

Tak, są świetne, jeśli trzymasz to, co robisz z perspektywy. Jeśli jest to coś tak prostego, jak audyt, podsumowanie, automatyczne sekwencjonowanie itp., Nie ma problemu. Pamiętaj tylko o tempie wzrostu tabeli i o tym, jak wyzwalacz wpłynie na wydajność.


6

Na wysokim poziomie istnieją dwa przypadki użycia wyzwalaczy1

1) Aby rzeczy stały się „automagicznie”. W tym przypadku wyzwalacze powodują efekt uboczny, zmieniają dane w sposób, którego nie oczekiwano, biorąc pod uwagę (pierwotne) wstawianie, aktualizowanie lub usuwanie operatora, które zostało wykonane i spowodowało uruchomienie wyzwalacza.

Ogólny konsensus jest taki, że wyzwalacze są rzeczywiście szkodliwe. Ponieważ zmieniają dobrze znaną semantykę instrukcji INSERT, UPDATE lub DELETE. Zmiana semantyki tych trzech prymitywnych operatorów SQL ukąsi innych programistów, którzy w przyszłości będą musieli pracować nad tabelami bazy danych, które nie zachowują się już w oczekiwany sposób, gdy są obsługiwane na nich z operacjami podstawowymi SQL.

2) W celu egzekwowania zasad integralności danych, innych niż te, z którymi możemy postępować deklaratywnie (przy użyciu przycisku CHECK, KLUCZ PODSTAWOWY, KLUCZ UNIKALNY i KLUCZ ZAGRANICZNY). W tym przypadku użycia wszystkie wyzwalacze wykonują dane QUERY (SELECT), aby sprawdzić, czy zmiana wprowadzana przez INSERT / UPDATE / DELETE jest dozwolona, ​​czy nie. Podobnie jak w przypadku ograniczeń deklaracyjnych. Tylko w tym przypadku my (programiści) zaprogramowaliśmy wymuszanie.

Użycie wyzwalaczy w drugim przypadku użycia nie jest szkodliwe.

Bloguję na ten temat pod adresem : http://harmfultriggers.blogspot.com


Używanie wyzwalaczy dla integralności referencyjnej jest trudniejsze niż się wydaje, aby poradzić sobie z problemami współbieżności.
WW.

2
Zgoda. Ale czy jest łatwiej, gdy używasz innych środków?
Toon Koppelaars,

Twierdzę, że numer jeden jest szkodliwy tylko, jeśli masz niekompetentnych programistów.
HLGEM

Istnieje wiele niekompetentnych programistów, choć lol.
hashtable

5

Wiem, że programiści, którzy uważają, że wyzwalacze powinny być zawsze używani tam, gdzie jest to najbardziej bezpośredni sposób na osiągnięcie pożądanej funkcjonalności, oraz programiści, którzy nigdy nie będą. To prawie jak dogmat między obozami.

Jednak osobiście całkowicie zgadzam się z MarkR - zawsze możesz (prawie) zawsze napisać kod funkcjonalnie równoważny wyzwalaczowi, który będzie bardziej widoczny, a zatem łatwiejszy w utrzymaniu.


Tyle że nie wszystkie prace polegają na trafieniu do bazy danych przepływa przez kod aplikacji.
HLGEM

5

Nie zło W rzeczywistości upraszczają takie rzeczy

1. Logowanie / audyt zmian w rekordach, a nawet schematach baz danych

Możesz mieć wyzwalacz w ALTER TABLE, który wycofuje zmiany w środowisku produkcyjnym. Powinno to zapobiec przypadkowym modyfikacjom tabeli.


2.Wzmocnienie referencyjnej intrgity (relacje klucza podstawowego / obcego itp.) W wielu bazach danych


Czy możesz wycofać instrukcje DDL?
Andrew Swan,

Generalnie nie. Jedynym sposobem na zatrzymanie tego jest usunięcie tego uprawnienia z loginów użytkowników.
jmucchiello,

W niektórych silnikach baz danych możesz (np. PostgreSQL).
Nicolás

@Andrew - W SQL Server możesz. SQL Server 2005+ ma również wyzwalacze DDL, które uruchamiają się w przypadku zdarzeń takich jak ALTER TABLE.
Martin Smith

4

Nie, nie są źli - są po prostu źle zrozumiani :-D

Wyzwalacze mają uzasadnione zastosowanie, ale zdecydowanie zbyt często jako hak retro, który ostatecznie pogarsza sytuację.

Jeśli tworzysz DB jako część aplikacji, logika powinna zawsze znajdować się w kodzie lub sprokach wykonujących wywołanie. Wyzwalacze doprowadzą później do bólu podczas debugowania.

Jeśli rozumiesz, w jaki sposób blokowanie, zakleszczanie i jak bazy danych uzyskują dostęp do plików na dysku, to użycie wyzwalaczy we właściwy sposób (na przykład inspekcja lub archiwizacja bezpośredniego dostępu do bazy danych) może być naprawdę cenne.


4

Stwierdzenie, że są źli, jest przesadą, ale mogą powodować siatki. Gdy wystrzelenie jednego spustu powoduje uruchomienie innych spustów, staje się to naprawdę skomplikowane. Powiedzmy, że są kłopotliwe: http://www.oracle.com/technology/oramag/oracle/08-sep/o58asktom.html

Prowadzenie logiki biznesowej w Oracle za pomocą wyzwalaczy jest trudniejsze niż się wydaje z powodu problemów z wieloma współbieżnościami. Nie zobaczysz zmian w innej sesji, dopóki inne sesje się nie zatwierdzą.


4

Na pewno nie są źli. Znalazłem wyzwalacze cenne podczas refaktoryzacji schematów bazy danych, podczas zmiany nazwy kolumny lub podziału kolumny na dwie kolumny lub odwrotnie (przykład: przypadek imię / nazwisko) i pomoc w przejściu.

Są również bardzo przydatne do audytu.


4

Ta odpowiedź dotyczy w szczególności programu SQL Server. (chociaż może to dotyczyć także innych RDBMS, nie mam pojęcia. Wolałbym udzielić go tutaj jako odpowiedzi , ale zostało to zamknięte jako duplikat tego).

Jednym z aspektów nie wymienionych w żadnej z dotychczasowych odpowiedzi jest bezpieczeństwo. Ponieważ domyślnie wyzwalacze są wykonywane w kontekście użytkownika, który wykonuje instrukcję, która powoduje uruchomienie wyzwalacza, może to powodować zagrożenie bezpieczeństwa, chyba że wszystkie wyzwalacze zostaną przejrzane.

Przykład podany w BOL pod nagłówkiem „ Managing Trigger Security ” to użytkownik, który tworzy wyzwalacz zawierający kod GRANT CONTROL SERVER TO JohnDoe ;w celu eskalacji własnych uprawnień.


3

Jeśli występują efekty uboczne, jest to problem z założenia. W niektórych systemach baz danych nie ma innej możliwości ustawienia pola autowzrostu, tj. Dla pola identyfikatora klucza podstawowego.


3

Myślę, że mogą być źli, ale tylko tak źli, jak wszystko inne w rozwoju.

Chociaż tak naprawdę nie mam z nimi dużego doświadczenia, miałem je przy ostatnim projekcie, nad którym pracowałem, co doprowadziło mnie do tego wniosku. Problem, który mam z nimi, może spowodować, że logika biznesowa skończy w dwóch lokalizacjach, bibliotece kodów i bazie danych.

Widzę to jako podobny argument przy użyciu sproców. Często będziesz mieć programistów, którzy są naprawdę dobrzy w pisaniu logiki biznesowej SQL do bazy danych, podczas gdy ludzie, którzy nie są, będą mieli logikę biznesową gdzie indziej.

Zatem moją ogólną zasadą jest przyjrzenie się strukturze twojego projektu. Jeśli logika biznesowa przechowywana w bazie danych wydaje się opłacalna, przydatne mogą być wyzwalacze.


1

Rzeczywiście, dość często wyzwalacze są niewłaściwie wykorzystywane. Właściwie w większości przypadków nawet ich nie potrzebujesz. Ale to niekoniecznie czyni ich złymi.

Przyszedł mi do głowy scenariusz, w którym wyzwalacze są przydatne, gdy masz starszą aplikację, dla której nie masz kodu źródłowego i nie ma sposobu, aby go zmienić.


1

Idea wyzwalaczy nie jest złem, ograniczanie zagnieżdżania wyzwalaczy jest złem.

Korzystając z naszej strony potwierdzasz, że przeczytałeś(-aś) i rozumiesz nasze zasady używania plików cookie i zasady ochrony prywatności.
Licensed under cc by-sa 3.0 with attribution required.