DML triggers are invoked when a DML event
occurs in the database. DML events manipulate or modify the data in a
table or view. These events include insertions, updates, and deletions.
DML triggers are powerful objects for maintaining
database integrity and consistency. They are able to evaluate data
before it has been committed to the database. During this evaluation
period, these triggers can perform a myriad of actions, including the
following:
Compare before and after versions of data.
Roll back invalid modifications.
Read from other tables, including those in other databases.
Modify other tables, including those in other databases.
Execute local and remote stored procedures.
Based on the nature of these actions, triggers were
originally used in many cases to enforce referential integrity. Triggers
were used when foreign key columns in one table had to be validated
against primary keys or unique index values in another table. The
triggers could fire when data was modified, and validations could be
performed to ensure that referential integrity was maintained.
The
advent of declarative referential integrity (DRI) diminished the need
for referential integrity triggers. DRI is now generally implemented
with database objects such as foreign key constraints that perform the
referential integrity validation internally. Because of this, triggers
generally handle more complex integrity concepts and enforce
restrictions that cannot be handled through data types, constraints,
defaults, or rules. Following are some examples of trigger uses:
Maintenance of duplicate and derived data—
A denormalized database generally introduces data duplications (that
is, redundancy). Instead of exposing this redundancy to end users and
programmers, you can keep the data in sync by using triggers. If the
derived data is allowed to be out of sync, you might want to consider
handling refreshes through batch processing or some other method
instead.
Complex column constraints—
If a column constraint depends on other rows within the same table or
rows in other tables, using a trigger is the best method for that column
constraint.
Complex defaults— You can use a trigger to generate default values based on data in other columns, rows, or tables.
Inter-database referential integrity—
When related tables are found in two different databases, you can use
triggers to ensure referential integrity across the databases.
You can use stored procedures for all these tasks,
but the advantage of using triggers is that they fire on all data
modifications. Stored procedure code or SQL in application code is
executed only when it makes the data modifications. With triggers, all
data modifications are subject to the trigger code, except for bulk copy
and a few other nonlogged actions. Even if a user utilizes an ad hoc
tool, such as SQL Server Management Studio (SSMS) to make changes to the
database, the integrity rules cannot be bypassed after the trigger is
in place.
Note
Triggers and stored procedures are not mutually
exclusive. You can have both triggers and stored procedures that perform
modifications and validation on that same table. If desired, you can
perform some tasks via triggers and other tasks via stored procedures.
1. Creating DML Triggers
You can create and manage triggers in SQL Server
Management Studio or directly via Transact-SQL (T-SQL) statements. The
Object Explorer in SSMS provides a simple means of creating triggers
that you can use to generate the underlying T-SQL code. You expand the
Object Explorer tree to the user table level and then right-click the Triggers node. When you select the New Trigger option, as shown in Figure 1, the trigger template shown in the right pane of Figure 30.1 appears.
You can populate the trigger template by manually
editing it, or you can select the Query menu option Specify Values for
Template Parameters. When you select Specify Values for Template
Parameters, a screen appears, allowing you to fill in the basic values
for the trigger, including the table that the trigger will be on and the
events to respond to.
You can launch the New Trigger template and other
templates related to triggers via the Template Explorer, which you open
by selecting View, Template Explorer in SSMS. Figure 2 shows a partial list of the available templates, including those related to triggers.
All the trigger templates provide a basic framework
for you to create a trigger, but the core logic is up to you. Existing
triggers or sample triggers are often good alternatives to the templates
because they offer more of the core logic. You can right-click a
trigger in the Object Explorer and select the Script Trigger As option.
This option contains several different methods to script the trigger.
After you script a trigger, you can modify it as necessary to meet your
needs.
Tip
Using the sys.triggers catalog view is a
good way to list all the triggers in a database. To use it, you simply
open a new query editor window in SSMS and select all the rows from the
view as shown in the following example:
SELECT * FROM sys.triggers
After
you have a basic trigger template, you can code the trigger, with
limited restrictions. Almost every T-SQL statement you would use in a
SQL batch or stored procedure is also available for use in the trigger
code. However, you cannot use the following commands in a DML trigger:
The following sections describe the different types of DML triggers that can be coded and some of their common uses.
