|
Three trusty rules for DB2 triggers
by Craig Mullins
Triggers are very handy. In this tip, DB2portal.com's Craig Mullins
lays out his general rules of thumb for triggers:
Favor triggers when data modifications can be
done outside the control of planned applications. Doing so will
enforce your integrity constraints in the triggers that would not
be enforced otherwise.
Triggers are less efficient than constraints.
If you can accomplish the same effect with referential, unique or
check constraints do so, as it will be more efficient.
If all modifications to the data are done through
transactions, performing the code in the application logic instead
of a trigger will likely be more efficient. As with most things,
your exact mileage will vary. In other words, you should investigate
using triggers where it makes sense given the business rules that
apply to your data. For applications with very high transaction
rates be sure to thoroughly test the impact of triggers on your
system before committing to them. Triggers provide many potential
benefits for enhancing DB2 databases. With triggers your DB2 tables
can become active -- meaning that DB2 will take action implicitly
as the data in the database is modified. Triggers are a very powerful
way to enhance the data integrity of your DB2 databases.
Still, keep these additional cautions in mind:
- When triggers are added to a table, they are not effective on
existing data.
- Triggers are not fired for the LOAD Utility (except for the LOAD
SHRLEVEL CHANGE).
|
