Introduction

A database trigger is a special stored procedure that is run when specific actions occur within a database. Most triggers are defined to run when changes are made to a table’s data. Triggers can be defined to run instead of or after DML (Data Manipulation Language) actions such as INSERT, UPDATE, and DELETE.

Triggers help the database designer ensure certain actions, such as maintaining an audit file, are completed regardless of which program or user makes changes to the data.

The programs are called triggers since an event, such as adding a record to a table, fires their execution.

Triggers and their implementations are specific to database vendors. In this article, we’ll focus on Microsoft SQL Server; however, the concepts are the same or similar in Oracle and MySQL.

Note: All the examples for this lesson are based on Microsoft SQL Server Management Studio and the AdventureWorks2012 database. You can get started using these free tools using my Guide Getting Started Using SQL Server.

Events

The triggers can occur AFTER or INSTEAD OF a DML action. Triggers are associated with the database DML actions INSERT, UPDATE, and DELETE. Triggers are defined to run when these actions are executed on a specific table.

AFTER Triggers

Once the DML actions, such as an INSERT completes, the AFTER trigger executes. Here are some key characteristics of AFTER triggers:

After triggers are run after a DML action, such as an INSERT statement and any ensuing referential cascade actions and constraint checks have run.
You can’t cancel the database action using an AFTER trigger. This is because the action has already completed.
One or more AFTER triggers per action can be defined on a table, but to keep things simple, I recommend only defining one.
You can’t define AFTER triggers on views.

INSTEAD OF Triggers

INSTEAD OF triggers, as their name implies, run in place of the DML action which caused them to fire. Items to consider when using INSTEAD OF triggers include:

An INSTEAD OF trigger overrides the triggering action. If an INSTEAD OF trigger is defined to execute on an INSERT statement, then once the INSERT statement attempts to run, control is immediately passed to the INSTEAD OF trigger.
At most, one INSTEAD OF trigger can be defined per action for a table. This makes sense, as if you had to “INSTEAD OF” triggers for an insert, which one should run?

Special Database Objects

Triggers use two special database objects, INSERTED and DELETED, to access rows affected by the database actions. Within the scope of a trigger, the INSERTED and DELETE objects have the same columns as the trigger’s table.

The INSERTED table contains all the new values; whereas, the DELETED table contains old values. Here is how the tables are used:

INSERT – Use the INSERTED table to determine which rows were added to the table.
DELETE – Use the DELETED table to see which rows were removed from the table.
UPDATE – Use the INSERTED table to inspect the new or updated values and the DELETED table to see the values prior to update.

Definition

A trigger is defined for a specific table and one or more events. In most database management systems, you can only define one trigger per table.

Below is an example trigger from the AdventureWorks2012 database.

You’ll notice the syntax for a trigger is very similar to that of a stored procedure. In fact, the trigger uses the same language to implement its logic as do stored procedures. In MS SQL, this is T-SQL; whereas in Oracle, it is PL/SQL.

Here are some important parts to a trigger:

The CREATE statement – It defines which table is associated with the trigger. In addition, this statement is used to specify when the trigger executes (e.g., after insert).
The actual program. In the example, this program runs whenever one or more rows are inserted into the WorkOrder table.
Special database objects – Triggers use specially defined databases objects such as INSERTED, or DELETED to access records affected by the database action.
In this example, the trigger is using the INSERTED object to gain access to the newly created rows. The INSERT statement is used to table those rows and add them to a history table.

Uses for Triggers

Here are some common uses for triggers:

Complex Auditing

You can use triggers to track changes made to tables. In our example above, changes made to the WorkOrder table are recorded in a TransactionHistory table.

Typically when creating audit trails, you’ll use AFTER triggers.

You may think this is redundant, as many changes are logged in the databases journals, but the logs are meant for database recovery and aren’t easily accessible by user programs. The TransactionHistory table is easily referenced and can be incorporated into end user reports.

Enforce Business Rules

Triggers can be used to inspect all data before a DML action is performed. You can use INSTEAD OF triggers to “intercept” the pending DML operation, apply any business rules, and ultimately complete the transaction.

An example business rule may be that a customer status is defined as:

Gold – Purchases over $1,000,000 in the past 12 months
Silver – Purchase of $500,000 to $1,000,000 in the past 12 months
Bronze – All other purchase levels

An INSTEAD OF trigger could be defined to check the customer status each time a customer record is added or modified. The status check would involve creating a sum of all the customers’ purchases and ensuring the new status corresponds with the sum of the last 12 months of purchases.

Derive Column Values

Triggers can be used to calculate column values. For instance, for each customer, you may wish to maintain a TotalSales column on the customer record. Of course, for this to remain accurate, it would have to be updated every time a sales was made.

This could be done using an AFTER trigger on INSERT, UPDATE, and DELETE statements for the Sales table.

Triggers are Tricky!

In general, my advice is to avoid using triggers unless absolutely necessary.

You should avoid using triggers in place of built in features. For instance, rather than rely on triggers to enforce referential integrity, you’re better off using relationships.

Here are some reasons why I shy away from them:

They can be hard to troubleshoot.
Triggers can cause other triggers to fire. Two Tables, A and B, both have an AFTER UPDATE trigger. If the AFTER UPDATE trigger on Table A updates Table B, then updating Table A causes its trigger and then B’s trigger to Fire.
You have to be sure you don’t create a trigger storm! Can you imagine if Table B, for some reason, updated Table A? Now you have a circular reference… Boom!
I try to move as much logic into Stored Procedures and have applications make changes to the database through them rather than straight up SQL statements.

The post What is a Database Trigger? appeared first on Essential SQL.