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

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.

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.

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.

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

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 ...

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.

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.

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ć ...

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”.

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ść.

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

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.

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

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.

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ą.

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.

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ń.

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.

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.

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ć.

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