Triggery - zlo czy magiczny czarodziej dla aplikacji?

Siema mam do was szybkie pytanie, czy uwazacie ze triggery zaburzaja architekture aplikacji i powinno sie to wepchnac do kodu, czy jest to jak najbardziej w porzadku i to, czy bedzie to w kodzie, czy w bazie nie ma znaczenia, wystarczy tylko zapoznac sie z projektem?

Ma znaczenie. Powinnny być w bazie.

Dopnę się do pytania, do jakich celów zazwyczaj wykorzystuje się właśnie mechanizm triggerów?

wpychanie logiki do triggeerow jest złe. bazodanowcy powiedzą że dobre programiści Java powiedzą że złe. teraz zależy komu bardziej ufasz. trigery są fajne np do rzeczy które często poprawiacie na produkcji z palca na bazce. np update timestampow changed i takie tam różne z rzeczy których korzysta potem appka a ręcznie robiąc xos na bazce można o tym zapomnieć

Ja (nie wiem czy poprawnie ;)) często w ten sposób uzupełniam sobie kolumny z datami utworzenia/modyfikacji rekordu na przykład.

Osobiście używam wyzwalaczy do prostych operacji. Typu nadzór nad modyfikacją danych lub/i wprowadzenie jakiejś wartości w inną kolumnę - np. daty utworzenia, modyfikacji, zaszyfrowanie danego pola itp. Twierdzę, że jest to bardzo przydatny mechanizm, który ułatwia wiele. Stworzenie tej samej logiki po stronie aplikacji może być po prostu bardziej czasochłonne. Jestem zwolennikiem tego, że to bardzo dobry mechanizm, ale do prostych zadań - bez przesady nie upychajmy tam nie wiadomo ile kodu.

Dobre do zarządzania polami niektórymi polami technicznymi (ostatnia data aktualizacja, użytkownik insertujący/updatujący itp.).
Złe do uzupełniania pól biznesowych. Chyba, że jest jakaś specyficzna logika stosowana bez wyjątku na każdej tablicy w danej warstwie, i jest to zaakceptowane na poziomie architektury.

Sory, za moje newbie, ale nie jestem programista, dlatego niektorych pojec nie rozumiem, a wynika to z tego, ze nie pracuje w tym zawodzie jeszcze i takie pojecia sa mi obce.
@karolinaa , moglabys wytlumaczyc co to jest xos?
Albo co to tak naprawde jest **pole biznesowe **?

To teraz moze napisze do czego ja zastosowalem triggery w mojej aplikacji, a uzylem tego miedzy innymi do zmiany stanu tabeli, ktora odzialowywuje na druga, np. w bazie mam tabele "premium", ktora wspolgra z tabela "users", zalozmy, ze ktorys rekord z "premium" zostal usuniety to odpowiednio dziala na "users" albo pilnowanie timestampow, np. wlasnie do kont premium i takie duperele - jest to dobre wykorzystywanie triggerow?

Ogolnie chcialbym pojsc do pracy jako programista, zeby dowiedziec sie co to jest logika biznesowa itp. bo w domu sie tego nie naucze, ale cos pracodawcy mnie nie lubia, bo na 2 rozmowach bylem i konczylo sie na 2/3 etapie :D

Nie wiem, czy to trafne spostrzezenie bo nie jestem programista, ale mam wrazenie, ze takie wlasnie wywolacze powinny byc w bazie, nie mowie o duzych rzeczach, ale o tych co bylo ww. bo jest to czytelniejsze zarowno dla bazodanowca, jak i programisty. Gorzej jakby bylo w kodzie dla bazodanowca.

Czarny Kot napisał(a):

Siema mam do was szybkie pytanie, czy uwazacie ze triggery zaburzaja architekture aplikacji i powinno sie to wepchnac do kodu, czy jest to jak najbardziej w porzadku i to, czy bedzie to w kodzie, czy w bazie nie ma znaczenia, wystarczy tylko zapoznac sie z projektem?

Tak, zaburzają.
Na czym polega "trigger w kodzie" Twoim zdaniem? Bo to z definicji mechanizm bazodanowy.

Złoty Kot napisał(a):

Dopnę się do pytania, do jakich celów zazwyczaj wykorzystuje się właśnie mechanizm triggerów?

Generalnie, to do wkurzania wprowadzających poprawki w aplikacji programistów, którzy nie mają szans tego zdebugować i dowiedzieć się, co za magia odbywa się w bazie.

Baza danych jest od danych, nie od logiki biznesowej.

hipekk napisał(a):

Ja (nie wiem czy poprawnie ;)) często w ten sposób uzupełniam sobie kolumny z datami utworzenia/modyfikacji rekordu na przykład.

Nie używasz ORMa?

mariano901229 napisał(a):

Osobiście używam wyzwalaczy do prostych operacji. Typu nadzór nad modyfikacją danych lub/i wprowadzenie jakiejś wartości w inną kolumnę - np. daty utworzenia, modyfikacji, zaszyfrowanie danego pola itp. Twierdzę, że jest to bardzo przydatny mechanizm, który ułatwia wiele. Stworzenie tej samej logiki po stronie aplikacji może być po prostu bardziej czasochłonne.

Co jest bardziej czasochłonne?

1. Napisać raz mechanizm na około 100 linijek kodu (z dużą górką), który zadziała później dla każdej nowej tabeli.
2. Pisać triggery dla każdej tabeli oddzielnie, i poprawiać za każdym razem, gdy np. zmienisz jej nazwę.

Na czym polega "trigger w kodzie" Twoim zdaniem? Bo to z definicji mechanizm bazodanowy.
Chodzi o to, zeby gdzies w kodzie byla jakas funckja/metoda informujaca o tym co w tym momencie sie dzieje, np. usuniemy wiersz z tabeli, a trigger nam zrobi 3 inne rzeczy na tabelach, to zeby to bylo widac w kodzie, to trzeba jakas metode jednak wykonac.

Widze, ze ile programistow, tyle roznych opinii. Jedni mowia tak, drudzy tak. Trigger na pewno z pozoru wydaje sie wygodniejszy, ale w zmianach jest raczej gorszy.

Czarny Kot napisał(a):

Na czym polega "trigger w kodzie" Twoim zdaniem? Bo to z definicji mechanizm bazodanowy.
Chodzi o to, zeby gdzies w kodzie byla jakas funckja/metoda informujaca o tym co w tym momencie sie dzieje, np. usuniemy wiersz z tabeli, a trigger nam zrobi 3 inne rzeczy na tabelach, to zeby to bylo widac w kodzie, to trzeba jakas metode jednak wykonac.

Widze, ze ile programistow, tyle roznych opinii. Jedni mowia tak, drudzy tak. Trigger na pewno z pozoru wydaje sie wygodniejszy, ale w zmianach jest raczej gorszy.

Te odmienne opinie wynikają z doświadczenia (lub jego braku) konkretnej osoby, imho.
Gdyby taki programista-piewca triggerów miał do czynienia z systemem, który obsługuje setki (lub więcej) obiektów biznesowych o zmiennej logice lub z wysoką dynamiką zmian, to 10x by się zastanowił czy lepiej pisać trigger/procedurę czy jednak mieć to w modelu obiektowym.
I, jak słusznie zauważyłeś, trigger wymaga utrzymania. Oczywiście kod też, ale z dwojga złego wolę mieć logikę w kodzie a nie część w kodzie i bazie danych. Zwłaszcza, jeśli coś ma działać inaczej w zależności od XYZ...

Generalnie to temat rzeka (również w kontekście jak te metody wywołać w kodzie, bo przecież można po chamsku stosować IFologię, ale można też przy pomocy IoC/DI) i nie ma jednej prostej odpowiedzi. To zależy.

Heh, chyba dosc gleboki temat poruszylem. Generalnie Robie mala aplikacja, tak zebym chociaz troche odroznil sie od innych kandydujacych, wiec na razie pozostane przy tym, na czym stoje. Nie ma tam nic skomplikowanego, takich rzeczy to chcialbym sie nauczyc w pracy, wiec nie ma chyba co szarzowac. To moze tak na koniec, czym powinienem sie zainteresowac, jesli chodzi o back-end ujmujac problematyke wlasnei takich "triggerow" w "kodzie" ? Ogolnie pisze w PHP-ie bo obok pythona jest chyba najbardziej przyjazny dla osob ktore nie pisaly nigdy backendu. Ale rowniez jestem otwarty na propozycje z jezyka C#, bo cos tam go miznalem i byc moze pojde tez w ta strone.

somekind napisał(a):

Generalnie, to do wkurzania wprowadzających poprawki w aplikacji programistów, którzy nie mają szans tego zdebugować i dowiedzieć się, co za magia odbywa się w bazie.

To jest bardzo ważna rzecz. Później my programistki dostajemy jakiś WTF błąd, debugujemy się i trudno jest ustalić nagle czemu jakieś pole gdzieś w któreś encji zmieniło sobie jakieś pole STATUS, bo na 4 głębokości triggera w innej tabelce na ktorej to cos zupdateowal inny trigger cos sie zmienilo.

BAZODANOWCY OGARNIJCIE SIE!

hipekk napisał(a):

Ja (nie wiem czy poprawnie ;)) często w ten sposób uzupełniam sobie kolumny z datami utworzenia/modyfikacji rekordu na przykład.

Czy nie lepiej użyć default do tego celu?