Open Source RDBMS - Seamless, Scalable, Stable and Free

한국어 | Login |Register

Versions available for this page: CUBRID 8.3.0 |  CUBRID 8.3.1 |  CUBRID 8.4.0 |  CUBRID 8.4.1 |  CUBRID 8.4.3 |  CUBRID 9.0.0 | 

Guideline for TRIGGER Definition

Trigger definition provides various and powerful functionalities. Before creating a trigger, you must consider the following:

  • Does the trigger condition expression cause unexpected results (side effects)?
  • You must use the SQL statements within an expectable range.
  • Does the trigger action change the table given as its event target?
  • While this type of design is not forbidden in the trigger definition, it must be carefully applied, because a trigger can be created that falls into an infinite loop. When the trigger action modifies the event target table, the same trigger can be called again. If a trigger occurs in a statement that contains a WHERE clause, there is no side effect in the table affected by the WHERE clause.
  • Does the trigger cause unnecessary overhead?
  • If the desired action can be expressed more effectively in the source, implement it directly in the source.
  • Is the trigger executed recursively?
  • If the trigger action calls a trigger and this trigger calls the previous trigger again, a recursive loop is created in the database. If a recursive loop is created, the trigger may not be executed correctly, or the current session must be forced to terminate to break the ongoing infinite loop.
  • Is the trigger definition unique?
  • A trigger defined in the same table or the one started in the same action becomes the cause of an unrecoverable error. A trigger in the same table must have a different trigger event. In addition, trigger priority must be explicitly and unambiguously defined.