Re: "All triggers are evil",..., really?

I have personally avoided Triggers but I know they are sometimes the only
available alternative or short-cut. During design/development stage, we
ensure that the technical design does not rely on triggers, but proper
routines that are put in place for required business logic (except extreme
cases such as audit requirements etc.). From my experience, going for a
trigger would mean that developers have lost track of how and from where the
base table is getting hit, and yes this does happen as the support team
looses control of the changes being done to the system.

Apart from the trigger-disable aspect discussed earlier, trigger code cannot
be wrapped either. I know of a case where a client developers took advantage
of modifying open trigger code and messed up the data.

I know of another system that has reached its support limits because of
excessive use of triggers. Identifying the process logic or the business
flow is a very cumbersome job on this system. Making changes in this system
often results in conflict that cannot be tested before hand.

Avoding trigger can be a good practice but not rule of thumb.


-- 
Thanks!
Amar Kumar Padhi
Oracle DBA/Architect

Other related posts: