  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 conf