- Database triggers implement an object-oriented observer pattern,
which means they listen for an event and then take action. - A trigger name must be unique among triggers
but can duplicate the name of any other object in a schema
because triggers have their own namespace. - A namespace is a unique list of identifiers
maintained in the database catalog. - recompile triggers:
ALTER TRIGGER trigger_name COMPILE; - Triggering events communicate directly with the trigger.
You have no control over or visibility into how that communication occurs.
You have no data other than that which is available through
the system-defined event attributes. - But, you have access to the new and old pseudo-record types in row-level DML
and INSTEAD OF triggers. The trigger declaration inherits the declaration
of these values from the DML statement that fires it. - DML row-level and INSTEAD OF triggers call their trigger bodies
differently than statement level triggers.
When an event fires this type of trigger, the trigger declaration
spawns a run-time program unit.
The run-time program unit is the real “trigger” in this process.
The trigger makes available new and old pseudo-record structures
by communicating with the DML statement that fired it.
The trigger code block can access these pseudo-record structures
by calling them as bind variables.
The trigger code block is an anonymous PL/SQL block that is only
accessible through a trigger declaration. - Bind variables allow you to reach outside of a program’s scope.
The :in and : out variables are bind variables inside trigger bodies.
Only row-level triggers can reference these pseudo-record structure bind variables. - You can define multiple triggers on any object or event.
Oracle 11g provides you with no way to synchronize which trigger
fires first, second, or last.
Triggers can slow down your application interface, especially row-level statements.
.
punit
