Database trigger
From Wikipedia, the free encyclopedia
A database trigger is procedural code that is automatically executed in response to certain events on a particular table in a database. Triggers can restrict access to specific data, perform logging, or audit data modifications.
There are two classes of triggers, they are either "row triggers" or "statement triggers". With row triggers you can define an action for every row of a table, while statement triggers occur only once per INSERT, UPDATE, or DELETE statement. Triggers cannot be used to audit data retrieval.
Each class can be of several types. There are "BEFORE triggers" and "AFTER triggers" which identifies the time of execution of the trigger. There is also an "INSTEAD OF trigger" which is a conditional trigger that will fire instead of the triggering statement. However, "INSTEAD OF trigger" are available only for views.
There are typically three triggering EVENTS that cause trigger to 'fire':
- INSERT event (as a new record is being inserted into the database).
- UPDATE event (as a record is being changed).
- DELETE event (as a record is being deleted).
The SQL:2003 standard mandates that triggers give programmers access to record variables by means of a syntax such as REFERENCING NEW AS n. For example, if a trigger is monitoring for changes to a salary column one could write a trigger like the following:
CREATE TRIGGER salary_trigger
BEFORE UPDATE ON employee_table
REFERENCING NEW ROW AS n, OLD ROW AS o
FOR EACH ROW
IF n.salary <> o.salary THEN
do something here
END IF;
The major features and effects of database triggers are that they:
- do not accept parameters or arguments
- cannot perform commit or rollback operations because they are part of the triggering SQL statement (only through autonomous transactions)
- can cause mutating table errors, if they are poorly written.
Contents |
[edit] Triggers in Oracle
In addition to triggers that fire when data is modified, Oracle 9i supports triggers that fire when schema objects (that is, tables) are modified and when user logon or logoff events occur. These trigger types are referred to as "Schema-level triggers".
Schema-level triggers
- Before Create
- After Create
- Before Alter
- After Alter
- Before Drop
- After Drop
- Before Logoff
- After Logon
[edit] Triggers in Microsoft SQL Server
Microsoft SQL Server supports triggers either after or instead of an insert, update, or delete operation.
Microsoft SQL Server 2005 introduced support for Data Definition Language (DDL) triggers, which can fire in reaction to a very wide range of events, including:
- Drop table
- Create table
- Alter table
- Login events
A full list is available on MSDN.
[edit] Triggers in PostgreSQL
PostgreSQL introduced support for triggers in 1997. The following functionality in SQL:2003 is not implemented in PostgreSQL:
- SQL allows triggers to fire on updates to specific columns; PostgreSQL does not support this feature.
- The standard allows the execution of a number of other SQL statements than SELECT, INSERT, UPDATE, such as CREATE TABLE as the triggered action.
[edit] Triggers in MySQL
MySQL 5.0 introduced support for triggers. Some of the triggers MYSQL supports are
- INSERT Trigger
- UPDATE Trigger
- DELETE Trigger
select * from customartiss;
[edit] External links
- Microsoft SQL Server CREATE TRIGGER
- MySQL Database triggers
- DB2 CREATE TRIGGER statement
- PostgreSQL CREATE TRIGGER
