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

15
Triggers
Ah, triggers. Triggers are cool, triggers are neat, and triggers are our friends. At the very same time,
triggers are evil, triggers are ugly, and triggers are our enemy. In short, I am often asked, “Should I
use triggers?” The answer is, like most things in SQL, it depends. There’s little that’s black and
white in the wonderful world of SQL Server — triggers are definitely a very plain shade of gray.
From a beginner’s point of view (and by this chapter in this book, I hope you’re a lot less of a
beginner — but still . . . ), you really want to be certain you know what you’re doing before you go
the triggers route, so sit back, listen, learn, and decide for yourself whether they are right for you.
In this chapter, we’ll try to look at triggers in all of their colors — from black all the way to white
and a whole lot in between. The main issues we’ll be dealing with include:
❑ What is a trigger?
❑ Using triggers for more flexible referential integrity
❑ Using triggers to create flexible data integrity rules
❑ Using INSTEAD OF triggers to create more flexible updatable views
❑ Other common uses for triggers
❑ Controlling the firing order of triggers
❑ Performance considerations
By the time we’re done, you should have an idea of just how complex the decision about when
and where not to use triggers is. You’ll also have an inkling of just how powerful and flexible they
can be.
Most of all, if I’ve done my job well, you won’t be a trigger extremist (which so many SQL Server
people I meet are) with the distorted notion that triggers are evil and should never be used. Neither
will you side with at the other end of the spectrum, who think that triggers are the solution to all