Why NOT to use triggers in RDBMS….

Reason 1: Triggers are not maintenance friendly.

Triggers are basically “Side Effects” and too many of them will create complexity of understanding.
Triggers are “hidden” in data definition language (DDL).

Reason 1: Buggy triggers can create issues.

Any buggy code can create issues, but triggers have context to create tricky concurrency ones.
Triggers are fired even when transactions are rolled back. And that means, even if inserted rows rolled back, “after insert” triggers would have fired! If this fired triggers are doing something outside RDBMS (like sending mail), that will be a problem.
In general, triggers must not do anything with external entities if they are not participating in transaction.

Also, triggers must not work on mutating tables. This means if trigger is executed as result of query operating on table X, then trigger must not query table X. Simple reason is that for one query, trigger may be fired many times and each time trigger will see different data in table X. In general, it is difficult to keep entity integrity via triggers.

Advice: Treat triggers as last resort to solve a problem.

Source:oracle.com

  • RSS
  • Print
  • PDF
  • Twitter
  • del.icio.us
  • Facebook
  • LinkedIn
  • Google Bookmarks
  • Digg
  • Add to favorites
  • StumbleUpon

Comments 1

  1. silver bullion prices wrote:

    What a fantastic short article I really enjoyed reading it

    Posted 11 Jun 2011 at 11:50 am

Post a Comment

Your email is never published nor shared. Required fields are marked *