Designing Triggers |
This topic discusses the design of triggers. It includes the following topics:
Use the following guidelines when designing your triggers:
Use triggers to guarantee that when a specific operation is performed, related actions are performed.
Do not define triggers that duplicate features already built into Oracle Database. For example, do not define triggers to reject bad data if you can do the same checking through declarative integrity constraints.
Limit the size of triggers. If the logic for your trigger requires much more than 60 lines of PL/SQL code, it is better to include most of the code in a stored procedure and call the procedure from the trigger. The size of the trigger cannot be more than 32K.
Use triggers only for centralized, global operations that should be fired for the triggering statement, regardless of which user or database application issues the statement.
Do not create recursive triggers. For example, creating an AFTER UPDATE statement trigger on the employees table that itself issues an UPDATE statement on employees, causes the trigger to fire recursively until it has run out of memory.
Use triggers on DATABASE judiciously. They are executed for every user every time the event occurs on which the trigger is created.
When creating triggers with PL/SQL code, there are some restrictions that are not required for standard PL/SQL blocks. The following topics discuss these restrictions.
SQL Statements Allowed in Trigger Bodies
The body of a trigger can contain DML SQL statements. It can also contain SELECT statements, but they must be SELECT... INTO... statements or the SELECT statement in the definition of a cursor.
DDL statements are not allowed in the body of a trigger. Also, no transaction control statements are allowed in a trigger. ROLLBACK, COMMIT, and SAVEPOINT cannot be used.For system triggers, {CREATE/ALTER/DROP} TABLE statements and ALTER...COMPILE are allowed.
|
Note: A procedure called by a trigger cannot run the previous transaction control statements, because the procedure runs within the context of the trigger body. |
Statements inside a trigger can reference remote schema objects. However, pay special attention when calling remote procedures from within a local trigger. If a timestamp or signature mismatch is found during execution of the trigger, then the remote procedure is not run, and the trigger is invalidated.
Only committed triggers are fired. For example, if you create a trigger that should be fired after all CREATE events, then the trigger itself does not fire after the creation, because the correct information about this trigger was not committed at the time when the trigger on CREATE events was fired.
For example, if you execute the following SQL statement:
CREATE OR REPLACE TRIGGER my_trigger AFTER CREATE ON DATABASEBEGIN NULL;END;Then, trigger my_trigger is not fired after the creation of my_trigger. Oracle Database does not fire a trigger that is not committed.
To create a trigger in your schema, you must have the CREATE TRIGGER system privilege, and either:
Own the table specified in the triggering statement, or
Have the ALTER privilege for the table in the triggering statement, or
Have the ALTER ANY TABLE system privilege
To create a trigger in another user's schema, or to reference a table in another schema from a trigger in your schema, you must have the CREATE ANY TRIGGER system privilege. With this privilege, the trigger can be created in any schema and can be associated with any user's table. In addition, the user creating the trigger must also have EXECUTE privilege on the referenced procedures, functions, or packages.
To create a trigger on DATABASE, you must have the ADMINISTER DATABASE TRIGGER privilege. If this privilege is later revoked, then you can drop the trigger, but not alter it.
The object privileges to the schema objects referenced in the trigger body must be granted to the trigger owner explicitly (not through a role). The statements in the trigger body operate under the privilege domain of the trigger owner, not the privilege domain of the user issuing the triggering statement. This is similar to the privilege model for stored procedures.