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
INSTEAD OF triggers to create more flexible updatable views
Other common uses for triggers
Controlling the firing order of triggers
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 ...