Oracle FAQ Your Portal to the Oracle Knowledge Grid
HOME | ASK QUESTION | ADD INFO | SEARCH | E-MAIL US
 

Home -> Community -> Usenet -> c.d.o.misc -> Re: Triggers : Performance Trade Off?

Re: Triggers : Performance Trade Off?

From: Tim Witort <trwNOSPAM_at_NOSPAMmedicalert.org>
Date: 1997/09/15
Message-ID: <341DC214.6499@NOSPAMmedicalert.org>#1/1

Jcen wrote:
>
> Hi,
>
> I have a database on hand to manage ever since I took over the
> responsibility of looking after this baby.
> I discover that no trigger was programmed into the database.
> Anything that seems great and beneficial to have triggers are coded in
> Stored Procedures instead.
> I am wondering, was the avoidance of triggers due to a performance
> issue?
> Would having triggers slow down a database?
> Would it be faster to have the code in a stored procedure than in a
> separate trigger procedures?

Triggers and procedures really serve different purposes. Triggers execute in response to some activity on a particular table: inserts, updates, deletes. And they happen transparently for the most part. Procedures, on the other hand, must be explicitly CALLED. So triggers are usually used to enforce business rules, audit transactions, compute derived columns, etc. Whereas procedures are called with arguments to perform some action or derive/manipulate data and can be envoked at will.

So if you need to
have something happen when an insert, update or delete happens, then a trigger is what you need.

If you need to do any sort
of processing regardless of insert, updates, or deletes, then a procedure is what you need. For example you can call a procedure from a SELECT statement to derive some complicated data, but since a trigger only fires on insert, update, or delete it is not an option for a SELECT statement.

There. That was sufficiently unclear. :^/

Received on Mon Sep 15 1997 - 00:00:00 CDT

Original text of this message

HOME | ASK QUESTION | ADD INFO | SEARCH | E-MAIL US