- Enforcing referential integrity: Although I recommend using Declarative Referential Integrity (DRI) whenever possible, there are many things that DRI will not do (for example, referential integrity across databases or even servers, many complex types of relationships, and so on).
- Creating audit trails: This means writing out records that keep track of not just the most current data, but also the actual change history for each record. This may eventually become less popular with the change-data tracking that SQL Server 2008 added, but triggers are still a pretty popular choice.
- Creating functionality similar to a CHECK constraint: Unlike CHECK constraints, this can work across tables, databases, or even servers.
Substituting your own statements in the place of the action statement of a user:
This is typically used to enable inserts in complex views.
- In addition, you have the new, but rarer case of the Data Defi nition Language (DDL) trigger, which is about monitoring changes in the structure of your table. And these are just a few. So, with no further ado, it is time to look at exactly what a trigger is.