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

SQL Server 6.5 and prior did not allow multiple triggers of the same type on any single table. For example,
if you had already declared a trigger called trgCheck to enforce data integrity on updates and inserts,
then you couldn’t create a separate trigger for cascading updates. Once one update (or insert, or delete)
trigger was created, that was it — you couldn’t create another trigger for the same type of action. WITH
APPEND gets around this problem by explicitly telling SQL Server that we want to add this new trigger
even though we already have a trigger of that type on the table — both will be fired when the appropriate
trigger action (INSERT, UPDATE, DELETE) occurs. It’s a way of having a bit of both worlds.
NOT FOR REPLICATION
AS
Adding this option slightly alters the rules for when the trigger is fired. With this option in place, the trigger
will not be fired whenever a replication-related task modifies your table. Usually a trigger is fired (to do
the housekeeping, cascading, and so on) when the original table is modified and there is often no point
in doing it again.
Exactly as it was with sprocs, this is the meat of the matter. The AS keyword tells SQL Server that your
code is about to start. From this point forward, we’re into the scripted portion of your trigger.
Using Triggers for Data Integrity Rules
Although they shouldn’t be your first option, triggers can also perform the same functionality as a CHECK
constraint or even a DEFAULT. The answer to the question “Should I use triggers vs. CHECK constraints?”
is the rather definitive: “It depends.” If a CHECK can do the job, then it’s probably the preferable choice.
There are times, however, when a CHECK constraint just won’t do the job, or when something inherent in
the CHECK process makes it less desirable than a trigger. Examples of where you would want to use a
trigger over a CHECK include:
❑ Your business rule needs to reference data in a separate table.
❑ Your business rule needs to check the delta (difference between before and after) of an UPDATE.
❑ You require a customized error message.
Chapter 15: Triggers
A summary table of when to use what type of data integrity mechanism is provided at the end of
Chapter 6.
This really just scratches the surface of things. Since triggers are highly flexible, deciding when to use
them really just comes down to balancing your need to get something special done with the overhead
triggers incur and other approaches you might take to address your need.
Dealing with Requirements Sourced from Other Tables
CHECK constraints are great — fast and efficient — but they don’t do everything you’d like them to. Perhaps
the biggest shortcoming shows up when you need to verify data across tables.
457