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". Row triggers 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 via SELECT statements.
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 trigger that will execute instead of the triggering statement.
There are typically three triggering events that cause triggers 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 trigger is used to automate DML condition process.
The major features of database triggers, and their effects, are:
- do not accept parameters or arguments (but may store affected-data in temporary tables)
- 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
- After Creation
- Before Alter
- After Alter
- Before Drop
- After Drop
- Before Logoff
- After Logon
The two main types of triggers are: 1) Instead of Trigger 2) After Triggers
[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 supports triggers on tables and views with the constraint that a view can be referenced only by an INSTEAD OF trigger.
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.
Performing conditional actions in triggers (or testing data following modification) is done through accessing the temporary Inserted and Deleted tables.
Visit MSDN for information on using Inserted and Deleted tables
[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 SQL statements other than SELECT, INSERT, UPDATE, such as CREATE TABLE as the triggered action.
Synopsis:
CREATE TRIGGER name { BEFORE | AFTER } { event [ OR ... ] }
ON table [ FOR [ EACH ] { ROW | STATEMENT } ]
EXECUTE PROCEDURE funcname ( arguments )
[edit] Triggers in MySQL
MySQL 5.0.2 introduced support for triggers. Some of the triggers MYSQL supports are
- INSERT Trigger
- UPDATE Trigger
- DELETE Trigger
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
END IF;
[edit] Triggers in CUBRID
CUBRID supports triggers on a table or a table column, and on a transaction. eg:
create trigger deferred_check_on_cost
deferred update on accommodations
if obj.cost < 0
execute invalidate transaction;
it means at the end of a transation to update table accommodations, check whether obj.cost < 0, if true, roll back the transaction.
[edit] Triggers in native XML database Sedna
Sedna provides support for triggers based on XQuery. Triggers in Sedna were designed to be analogous to SQL:2003 triggers, but natively base on XML query and update languages (XPath, XQuery and XML update language).
A trigger in Sedna is set on any nodes of an XML document stored in database. When these nodes are updated, the trigger automatically executes XQuery queries and updates specified in its body. For example, the following trigger tr3 cancels person node deletion if there are any open auctions referenced by this person:
CREATE TRIGGER "tr3"
BEFORE DELETE
ON doc("auction")/site//person
FOR EACH NODE
DO
{
if(exists($WHERE//open_auction/bidder/personref/@person=$OLD/@id))
then ( )
else $OLD;
}
More details on the syntax, execution semantics and usage of Sedna triggers are available in Sedna Programmer's Guide.
[edit] External links
- Microsoft SQL Server CREATE TRIGGER
- Microsoft SQL Server DROP TRIGGER
- MySQL Database triggers
- DB2 CREATE TRIGGER statement
- Oracle CREATE TRIGGER
- PostgreSQL CREATE TRIGGER
- Sedna XQuery Triggers
- How to get Rid of Mutating Table Error?
|
||||||||||||||||||||
