[eg0master]

Hehe... ok då kör vi...

Att använda sig av cascading deletes elelr att rensa saker i tabell B pga att en trigger körs pga en händelse i tabell A är ont. Varför? Jo för att när någon annan ska använda datatabasen än den som ursprungligen designade den eller upphovsmannen helt enkelt är glömsk så blir det en överraskning att en delete i persontabellen även resulterade i att massor av annat data deletas också. Det finns även en säkerhetsaspekt här. Vi fortsätter med delete exemplet: Om du av misstag råkar göra "delete from person where 1=1" så raderas i princip allt data ur din databas. Om du istället manuellt (500 rader perl verkar omständigt om det inte är 500 olika tabeller det skall raderas i) raderar det som är beroende av person så riskerar du inte att radera för mycket. Dessutom ser du (och någon annan som jobbar med databasen) vilka beroende som finns.
Exempel: Jag ska hjälpa dig och implementera en funktion som tar bort alla artiklar en person skrivit. Jag gör delete på tabellen och då visar det sig att det fanns ett beroende till en favoriter. Nu vet jag eftersom deleten misslyckades att kommentarer också måste raderas och det kanske vi inte vill (för personer som markerat en artikel som favorit kanske måste godkänna att den raderas).

Det är på detta sätt triggers ofta missbrukas. Man är för lat att göra saker i sin applikation i rätt ordning och på så sätt får operationer oväntade beteenden (för det är oväntat att en delete i en tabell genererar delete i en massa andra tabeller).

Så när (i min mening) är triggers bra?
Ja, exemplet med sybase där man gör systemunderhåll ligger väl i gränslandet (varför inte en schemalagd händelse som rensar istället).

Själv använder jag bara triggers för att skydda mina databaser mot utvecklare som skriver felaktig kod.
Exempel: En trigger som förhindrar att mer än en person raderas åt gången. Eller en trigger som förhindrar att en skickad faktura raderas ur databasen osv.
Alla saker som triggern kollar skall kollas i applikationen, men om det finns en bug i logiken är triggern sista utposten som förhindrar att en felaktig operation på just den tabellen görs. En trigger bör (enligt alla databasmänniskor jag känner) aldrig ändra data. bara kontrollera data och eventuellt generera ett fel och en rollback.