Toon Koppelaars
"Triggers Considered Harmful: Considered Harmful"(1)
Oracle rockstar Tom Kyte (asktom.oracle.com en
tkyte.blogspot.com) is fervent tegenstander van het gebruik
van database triggers: "All triggers are evil. Why? Because they make things happen automagically."
Ik heb wel begrip voor zijn standpunt, maar probeer
het tegelijk ook enigszins te nuanceren. Met dat all things
happen automagically doelt hij op triggers waarin code
zit die dingen veranderen. Bijvoorbeeld, :new-column
waarden overschrijven of, erger nog, DML-statements
uitvoeren. Feitelijk passen deze triggers de semantiek
van insert, update en delete statements aan. Een singlerow
insert op een tabel met zo´n trigger kan dan allerlei
side effects krijgen. Side effects waar de schrijver van het
insert statement (die gewoon 1 row wilde toevoegen)
wellicht niet op voorbereid was.
De nuancering die ik altijd aanbreng gaat als volgt.
Je kunt triggers voor twee doelen gebruiken.
- Om zaken automagically te laten gebeuren.
- Om data integrity constraints af te dwingen.
Als u frequent lezer bent van deze column, kent u ondertussen
mijn view op een database applicatie. Je kunt in
zo´n applicatie drie soorten code onderscheiden: user
interface (UI) code, business logic (BL) code en data
logic (DL) code. Tom heeft het over triggers waarin je
BL code uitvoert, wat overeenkomt met het eerstgenoemde
doel hierboven. En ik ben het helemaal eens met zijn
stelling in deze: dit is "evil" gebruik van triggers om alle
redenen die Tom aanhaalt. Trouwens, andere database
features zoals de cascade-delete clause van een foreign
key, de default-clause bij een table, en het fixed length
CHAR-datatype (met haar auto rpadding), liggen wat
mij betreft in hetzelfde bakje: conceptueel zijn dit declaratieve
triggers die dingen automagically aanpassen en
zijn dus "to be considered harmful."
Echter je kunt triggers ook gebruiken voor het tweede
doel: het afdwingen van constraints. Triggers zullen in
dit geval alleen maar queries uitvoeren, en nooit inserts,
updates of deletes. Constraints afdwingen met triggers is
welliswaar complexer dan menig Oracle developer denkt
dat het is (concurrency en efficiency zijn de angels die het
complex maken). Er zijn dan ook legio triggers in Oracle
databases all over the world die foutief het tweede doel
implementeren. Waardoor, zo gaat het argument van Tom, dus ook voor dat doel triggers als evil en harmful beschouwd
moeten worden. En precies dit vind ik "considered harmful."
Als het complex is om een bepaalde taak met een bepaalde
toolset uit te voeren, wil dat a-priori niet zeggen dat de toolset
slecht is. Wellicht moet de vakman die de toolset gebruikt
gewoon wat beter opgeleid en getraind worden. Met de juiste
bagage kan elke Oracle developer middels triggers data
integrity constraints correct afdwingen.
Ook constraints die we declaratief kunnen implementeren
worden feitelijk door een trigger mechanisme afgedwongen.
Kijk bijvoorbeeld naar een foreign key: een foreign key is
conceptueel een set declarative triggers die op de juiste
momenten bij inserts, updates of deletes van rows in de betrokken
tabellen, DL code (met queries) uitvoeren om de
constraint af te dwingen. Trace het deleten van een parentrow
maar eens waarbij de foreign key column in de child
table niet geïndexeerd is: je ziet dan dat Oracle een query
op de child table uitvoert. Met een index zie je niks, maar
dat komt omdat Oracle in dat geval de SQL layer niet nodig
heeft om één en ander te controleren. En bij een primary
key maakt Oracle handig gebruik van al aanwezig zijnde
trigger momenten die een unique B-tree moeten bijwerken.
Helaas hebben veel constraints nog een niet-declaratieve
implementatie nodig. Wat mij betreft blijven database
triggers het geëigende vehicle om deze te implementeren.
Pas als Oracle het CREATE ASSERTION statement support,
word ik lid van de Asktom fanclub en kan er één "considered
harmful" van bovenstaande titel weg.
Ir. Toon Koppelaars
(Toon(at)RuleGen.com)
(1) http://en.wikipedia.org/wiki/Considered_harmful
| 
