Czy naprawdę potrzebuję wyzwalaczy dla relacyjnej bazy danych, na przykład PostgreSQL?

Wiem, że wyzwalaczy można używać do sprawdzania poprawności przechowywanych danych w celu zachowania spójności bazy danych. Dlaczego jednak nie przeprowadzić walidacji danych po stronie aplikacji przed zapisaniem ich w bazie danych?

Na przykład przechowujemy klientów i chcemy przeprowadzić weryfikację, której nie można łatwo wykonać na poziomie DDL. https://severalnines.com/blog/postgresql-triggers-and-stored-function-basics

Innym przykładem jest audyt.

Aktualizacja

Jak działają wyzwalacze i transakcje w bazie danych. Na przykład, jeśli chcę przeprowadzić weryfikację wstawianych danych. Odbywa się to w ramach transakcji. Co dzieje się wcześniej: transakcja zostaje zatwierdzona lub wyzwalacz jest wykonywany?

To zależy od rodzaju budowanego systemu aplikacji:

• jeśli tworzysz system zorientowany na aplikacje, który zawiera tylko jedną główną aplikację, z dedykowaną bazą danych specjalnie dla tej aplikacji i idealnie jeden zespół odpowiedzialny za rozwijanie aplikacji i bazy danych obok siebie, możesz zachować całą logikę walidacji, a także audyt logika wewnątrz aplikacji.

  Główną zaletą tego rozwiązania jest to, że nie trzeba rozdzielać logiki biznesowej między aplikacją a bazą danych, dzięki czemu utrzymanie i rozwój systemu często staje się łatwiejszy. Jako bonus, nie wiążesz zbytnio aplikacji z konkretnym typem dostawcy DBMS lub DBMS. Takie podejście jest oczywiście wymagane, jeśli aplikacja chce mieć możliwość korzystania z lekkiego systemu DB, który nie zapewnia wyzwalaczy.

• Jeśli jednak utworzysz system, w którym wiele różnych aplikacji ma wspólną bazę danych, i nie może wcześniej przewidzieć, które aplikacje będą do niej zapisywać w przyszłości lub które zespoły opracują aplikacje do wypełniania danych w bazie danych w przyszłości, wówczas jest lepsze, że Twoja baza danych będzie odpowiedzialna za zagwarantowanie jak największej spójności danych. I tutaj wyzwalacze stają się naprawdę pomocne. W większych systemach ograniczenia referencyjne często nie są do tego wystarczające, ale wyzwalacz wywołujący procedurę przechowywaną może zaimplementować prawie każdy rodzaj sprawdzania poprawności, jakiego potrzebujesz.

Innym powodem używania wyzwalaczy może być wydajność: w skomplikowanych modelach danych często zdarza się spotykanie złożonych reguł spójności, które wymagają użycia wielu dodatkowych danych, które nie są częścią bieżącego zestawu roboczego dostępnego w aplikacji klienta. Przeniesienie wszystkich tych danych najpierw przez sieć w celu umożliwienia weryfikacji po stronie klienta może mieć znaczący wpływ na wydajność.

Zobacz także ten starszy post SE: Logika aplikacji Vs DB Trigger do czyszczenia bazy danych

Więc sam zdecyduj, jaki system budujesz, a następnie możesz podjąć uzasadnioną decyzję, czy wyzwalacze są właściwym narzędziem dla twojej sprawy, czy nie.

Myślę, że pytanie dotyczy odpowiedzialności za jakość danych.

Odpowiedź zależy od tego, jak widzisz system.

Jeśli widzisz bazę danych jako niezależną, odrębną i autonomiczną usługę niezależną od aplikacji, baza danych jest odpowiedzialna za zapewnienie spójności i jakości zawartych w niej danych. Zasadniczo dlatego, że ta baza danych może być używana przez inną aplikację, więc nie może polegać na tym, że druga aplikacja ma taką samą spójność i jakość zachowania. W takich okolicznościach baza danych musi zostać zaprojektowana w taki sposób, aby ujawniała interfejs API i zachowanie autonomiczne. W tym widoku są co najmniej dwie aplikacje, jedna z nich to baza danych, a druga to aplikacja, która z niej korzysta.

I odwrotnie, bazę danych można uznać za skomplikowaną formę pliku, który znajduje się pod bezpośrednią i całkowitą kontrolą aplikacji. W tym sensie baza danych staje się czystym narzędziem do serializacji i nawigacji po dokumentach. Może zapewniać pewne zaawansowane zachowania do obsługi zapytań i obsługi dokumentów (takie jak JSON lub narzędzia XML), ale z drugiej strony nie musi (tak jak większość strumieni plików). W takim przypadku program odpowiada za utrzymanie właściwego formatu i zawartości pliku. W tym widoku jest jedna aplikacja.

W obu widokach kolejnym pytaniem jest, jak obsługiwać korzystanie z bazy danych jako fantazyjnego pliku lub oddzielnej usługi. Możesz to osiągnąć poprzez:

• za pomocą narzędzi udostępnianych przez platformę bazy danych w postaci tabel / widoków / procedur przechowywanych / wyzwalaczy itp.
• zawijanie samej bazy danych w ramach usługi, z której muszą korzystać wszyscy klienci, aby uzyskać dostęp do bazy danych
• zawijanie bazy danych do biblioteki, z której muszą korzystać wszyscy klienci, aby uzyskać dostęp do danych.

Każda z nich ma swoje zalety / wady i będzie zależeć od architektonicznych ograniczeń środowiska, w którym działa system.

Niezależnie od tego, jaki widok bierzesz, zawsze opłaca się sprawdzać poprawność danych na granicach.

• Sprawdź poprawność pól w interfejsie użytkownika wprowadzanych przez użytkownika
• Sprawdź poprawność żądania sieci / interfejsu API przed opuszczeniem klienta
• Sprawdź poprawność żądania sieci / interfejsu API na serwerze, zanim cokolwiek zrobisz
• Sprawdź poprawność danych przekazywanych do reguł biznesowych
• Sprawdź poprawność danych przed utrwaleniem
• Sprawdź poprawność danych po odzyskaniu od trwałości
• i tak dalej

To, ile walidacji jest uzasadnione na każdej granicy, zależy od tego, jak ryzykowne jest jej niepotwierdzenie.

• pomnożenie dwóch liczb razem?
  • otrzymałeś zły numer, czy to problem?
• wywoływanie procedury dla danej lokalizacji pamięci?
  • Co jest w tej lokalizacji pamięci?
  • Co się stanie, jeśli obiekt nie istnieje lub jest w złym stanie?
• za pomocą wyrażenia regularnego w ciągu zawierającym kanji?
  • Czy moduł regex może obsłużyć Unicode?
  • Czy wyrażenie regularne może obsłużyć Unicode?

Nie, nigdy nie należy używać wyzwalaczy do sprawdzania poprawności.

Baza danych odpowiada tylko za swoją integralność. Weryfikacja użytkownika powinna zostać przeprowadzona przez aplikację.

Bazy danych wykonują trzy poziomy sprawdzania poprawności pod kątem integralności. Pierwszym z nich jest walidacja na poziomie pola. Pole może być wymagane, jeśli nie ma wartości (null), oznacza to błąd. Może to być również ograniczenie sprawdzające; domena ma wyliczoną liczbę wartości.

Po drugie, istnieją relacje między tabelami. W jednej tabeli przechowujesz jeden lub więcej kluczy obcych, odnosząc tę ​​tabelę do innych tabel i wymagając, aby wartości były poprawnymi kluczami dla „drugiej tabeli”. Pomyśl o bazie danych adresów, w której obsługujemy adresy różnych krajów. Klucz kraju w adresie musi wskazywać znany kraj. To, czy dane (np. Kod pocztowy) są prawidłowe, nie jest przedmiotem tej kontroli integralności.

Po trzecie i najbardziej skomplikowane są wyzwalacze. Zasadniczo powinny one dotyczyć (pun nie zamierzony) dotyczy warunkowych zasad uczciwości. Wracając do przykładu adresu: jeśli kraj nie ma kodów pocztowych, problem pojawiałby się, gdyby kraj z tej listy miał kod pocztowy. Tak więc czek byłby następujący: jeśli ten kraj nie ma kodów pocztowych, pole kodu pocztowego powinno być puste.

Walidacja jest przedmiotem wniosku. Fakt, że niemiecki kod pocztowy składa się tylko z cyfr, jest sprawdzianem, który powinna wykonać aplikacja, a nie baza danych. Linia jest cienka, więc w niektórych przypadkach może być potrzebne przemyślenie / omówienie, czy coś powinno być w wyzwalaczu (chroń integralność bazy danych) lub w aplikacji (walidacja przez użytkownika).

Audyt jest klasycznym przykładem skutecznego użycia wyzwalaczy. Znalazłem błędy popełniane przez testera (przenoszenie klienta z jednego poziomu usługi na inny) dzięki tabeli Audit, która została zaimplementowana przez wyzwalacze. Bardzo polecam używanie wyzwalaczy do kontroli.

Walidacji można dokonać na poziomie interfejsu, ale widziałem dziwne błędy w bazie danych, które obsługiwałem (ludzie, którzy urodzili się w 3000 itd.), A ponieważ niektóre z nich zrobiłem sam, bardzo polecam posiadanie dodatkowej warstwy walidacji w bazie danych, na wszelki wypadek. Oczywiście tego rodzaju błędów można uniknąć dzięki ograniczeniom sprawdzania i wiele razy są one bardziej skuteczne (w MS SQL są preferowaną metodą; zawsze sprawdzaj dokumentację).

Ponieważ pytanie dotyczy tego, czy naprawdę potrzebujemy wyzwalaczy dla relacyjnych baz danych, oto kilka innych przypadków użycia wyzwalaczy:

1. Do kontroli zgodnie z opisem w innych odpowiedziach.
2. Audyt w szerszym znaczeniu: jeśli pozycja bazy danych zostanie zmieniona, wyzwalacz może zarejestrować zdarzenie w celu asytronicznego przetwarzania końcowego, np. Nocne eksportowanie do innej aplikacji.
3. Wyzwalacze dla widoków: można zdefiniować wyzwalacze instead of. Dzięki temu można wstawiać, aktualizować i usuwać wpisy z widoku. Wyzwalacze mogą rozłożyć te działania na wiele tabel. Jest to sposób na udostępnienie ograniczonego widoku bez ujawniania szczegółów tabel bazowych.
4. Aby jawnie zapisać odwrócenie bazy danych: załóż relacje N: M między tabelą A i B a tabelą pośrednią R. Możesz zdefiniować ograniczenia klucza obcego od R do A, a także B, określając, że wpis w R ma zostać usunięty, jeśli jego odpowiadający wpis w B zostaje usunięty. Jednak logika biznesowa wymaga czasem, aby wpisy w A musiały mieć co najmniej jedną relację z wpisem w B. W tym przypadku wyzwalacz po usunięciu R może pomóc w egzekwowaniu tej logiki: jeśli dla wpisu w A ostatni wpis w R jest usuwany, a następnie wyzwalacz może usunąć A. W widoku centralnym aplikacji konieczne są co najmniej dwa zawracanie. To jest przykład walidacji. Możliwe są inne przykłady: oprócz przypadków użycia (1), (2),
5. Zaufanie: czasami administratorzy bazy danych zmieniają wpisy w wierszu poleceń, nie używając Twojej aplikacji. Administratorzy pracują ostrożnie i wiedzą, co robią. Czasami jednak mogą się mylić. Jeśli spójność ma kluczowe znaczenie, wyzwalaczem jest pas bezpieczeństwa.

Wadą logiki biznesowej jest rozłożona między warstwami, co stanowi poważną wadę w zakresie konserwacji. Jak napisał inny autor, jest to cienka granica między aplikacją a bazą danych, a wybór nie zawsze jest jasny. Moja osobista opinia jest taka, że ​​wyzwalacze obciążają programistów. Mogą zaoszczędzić czas na rozwój. Zdecydowanie zwiększają doświadczenie użytkowników, ponieważ zwiększają wydajność w przypadku wolnych połączeń sieciowych.