Database triggers, proti/za?

5 naročnikov

Zdravo,
mene zanimajo mnenja iz prakse glede uporabe prožilcev v podatkovni bazi oz. database triggerjev.
Še vedno razvijam sam, vendar se dostikrat postavim v kožo nekoga, ki bi delal na tem za mano ali ob meni.
Slabost, ki jo predvidevam, je ta da je triggerje težko dokumentirati v programu. Torej nekdo ki bi odprl razred Order, ne bi videl nobene dokumentacije o tem in bi se verjetno čudil, zakaj nimam funkcije, ki pri vnosu artikla v orderproduct tabelo poveča productssubtotal v tabeli order.
Zato razmišljam, da bi morda bilo dobro dati takim samodejno vzdrževanim stolpcem morda kakšen prefix, npr. productssubtotal.
Vendar ne vem, ali morda ne predvidevam še kakšne slabosti v tej separaciji, hm kako bi temu rekel... nizko nivojske podatkovne logike od objektne logike (?).

Kaj pa če zakomentiraš v razredu Order, da obstaja trigger za to in to...

Ja to bi eventuelno napisal v wiki-ju, vendar me zanima tudi kakšen predlog iz prakse, če sploh kdo uporablja triggerje in če, kakšen je pristop k temu :)

Čisto odvisno od situacije. Jaz jih bolj redko uporabljam (na Oraclu, na MySQL nikoli).
Uporabaljam pa jih samo takrat kadar je potrebno unique ID polja skopirati še v drugo polje v bazi (zato ker pri prenosu podatkov se unique IDji spremenijo). Ali pa se ID nastavi direktno iz za to predvidene sekvence.

Tudi na splošno pri nas težimo k temu, da se stvari rešujejo programsko, razen takšnih izjem kjer je preveč komplikacij.

Aha.
Torej po tvoje, mojega primera (products_subtotal) ne bi naredil s triggerjem ampak programsko.

Jaz kar je avtomatike na db uporabljam samo on update in on delete pri foreign keyih.

SlimDeluxe... zakaj pa ne bi naredil v kodi

UPDATE tablename SET products_subtotal=products_subtotal+1 WHERE pogoj

?

Glej na to s tega vidika, tudi če zadeve rešiš programsko, kot ti svetuje nekaj gornjih komentatorjev, ti bo bodoči razvijalec, ki ne bo vedel, da mora ob updatu nekega polja updatati tudi njegovo *_subtotals materializirano agregatno vrednost, lahko sesul konsistenco baze, če bo polje updatal na nekem drugem mestu v kodi. Za take zadeve so triggerji "a must", seveda moraš pa zadeve dovolj dobro dokumentirati.

BTW, tudi tale forum besno uporablja triggerje, če naštejem le en primer, število uporabnikovih objav, plusov, minusov in spamov so vse materializirane agregatne vrednosti, ažurirane s pomočjo triggerjev.

Gogy, ne vem, se mi zdi škoda da imaš tako uporabno zadevo kot je trigger in da se ne zmeniš za njo, ker kot vidiš tudi Vini pravi da je super stvar za agregatne vrednosti, za kar jih tudi sam želim uporabiti :)
Veš koliko krat narediš query samo da dobiš neko agregatno vrednost; skupno prodano kosov artikla, št. naročil stranke, skupno DDV za mesec...

Vini, btw kako pa imate v praksi narejeno dokumentacijo? Generiranje phpDoc, wiki... ?
In, ali si za te stolpce uporabil kakšen prefix. Malo se mi zdi potrebno, da bi te stolpce nekako ločil.

@SlimDeluxe, že že, vendar se mi je zdelo da imaš zadržke glede uporabe triggerja in sem mislil da lahko uporabiš UPDATE kot workaround.

@vini: kaj se pa zgodi ko nesposobni administratorji prenašajo bazo na boljši server pa ne prenesejo triggerjev, funkcij, sekvenc in ostalega sranja :D

Pazit moraš v vsakem primeru