Re: Triggers for RI extension only

["Mark S. Waterbury" <mark.s.waterbury@xxxxxxx>]

I think the real issue is this:

A "trigger" runs program sequentially, immediately before and/or after 
the I/O (get or put) operation, and before control returns to the 
application that initiated the I/O.

If the task requires more than a fairly trivial amount of code, and if 
it does not absolutely have to be done "in-line" within the actual 
trigger program, then it is probably a better design to use an 
asynchronous process to handle this task.

For example (from prior e-mails in this thread), suppose you need to 
send an e-mail notification to someone.  Rather than adding that code 
inside the trigger program itself, you could create a data queue for 
"event notification" and the trigger program writes to this data queue 
some information (presumably from the record being updated that fired 
the trigger in the first place).  Then, you have a pre-scheduled, 
long-running "server" job that listens to the data queue, and whenever 
an event arrives, processes it -- in this example, the listener job 
(program) sends an e-mail to someone to notify them that this "event" 
has occured.

HTH,

Mark S. Waterbury

> rob@xxxxxxxxx wrote:
> ...(snip)... But I sure wouldn't limit them to integrity only.
>
> Rob Berendt
>