Beginning Microsoft SQL Server 2008 ... - S3 Tech Training

Chapter 15: Triggers
Like regular triggers, INSTEAD OF triggers come in three different flavors: INSERT, UPDATE, and
DELETE. In each case, the most common use is the same — resolving ambiguity about which table(s) are
to receive the actual changes when you’re dealing with a view based on multiple tables.
Performance Considerations
I’ve seen what appear almost like holy wars happen over the pros and cons, evil and good, and light and
dark of triggers. The worst of it tends to come from purists — people who love the theory, and that’s all
they want to deal with, or people that have figured out how flexible triggers are and want to use them
for seemingly everything.
My two-bits worth on this is, as I stated early in the chapter, use them when they are the right things to
use. If that sounds sort of noncommittal and ambiguous — good! Programming is rarely black and white,
and databases are almost never that way. I will, however, point out some facts for you to think about.
Triggers Are Reactive Rather Than Proactive
What I mean here is that triggers happen after the fact. By the time that your trigger fires, the entire query
has run and your transaction has been logged (but not committed and only to the point of the statement
that fired your trigger). This means that if the trigger needs to roll things back, it has to undo what is
potentially a ton of work that’s already been done. Slow! Keep this knowledge in balance though. How
big an impact this adds up to depends strongly on how big your query is.
So what, you say. Well, compare this to the notion of constraints, which are proactive — that is, they happen
before your statement is really executed. That means they detect things that will fail and prevent
them from happening earlier in the process. This will usually mean that they will run at least slightly
faster — much faster on more complex queries. Note that this extra speed really shows itself to any significant
extent only when a rollback occurs.
What’s the end analysis here? Well, if you’re dealing with very few rollbacks, and/or the complexity and
execution time of the statements affected are low, then there probably isn’t much of a difference between
triggers and constraints. There’s some, but probably not much. If, however, the number of rollbacks is
unpredictable or you know it’s going to be high, you’ll want to stick with constraints if you can (and
frankly, I suggest sticking with constraints unless you have a very specific reason not to).
Triggers Don’t Have Concurrency Issues
with the Process That Fires Them
466
You may have noticed throughout this chapter that we often make use of the ROLLBACK statement, even
though we don’t issue a BEGIN TRAN. That’s because a trigger is always implicitly part of the same transaction
as the statement that caused the trigger to fire.
If the firing statement was not part of an explicit transaction (one where there was a BEGIN TRAN), then
it would still be part of its own one-statement transaction. In either case, a ROLLBACK TRAN issued inside
the trigger will still roll back the entire transaction.