RE: triggers within commit cycles

> From: R. Bruce Hoffman, Jr.

> And a program with a write statement instead of calling that I/O module is
> the same thing as executing DFU. It will circumvent your business rules. I
> know this could start a holy war, that's not my intention.

And a system where you don't know which programs are writing to your
database isn't a particularly secure system.  All I have to do is simply
secure all access to a file except by the I/O module.  What if someone turns
off your trigger?  That's just as likely as someone compiling and executing
a program that writes to a file they're not supposed to.  In fact, turning
off a trigger is more likely, because it's a single command.


> IMO, neither is perfect, but I have a better chance with my business rules
> in triggers than I do with an externalized I/O module. Even if I'm in an
> object oriented language.

A better chance of what?  Of writing a secure system?  Please.  As I said, I
just secure the file to the I/O module and I'm done.  Not only that, I'm
secure from unwarranted access via SQL and DFU.  I can secure access at the
column level, or by field content.

Also, I prefer the flexibility of being able to streamline my I/O when
needed, and changing or even circumventing processing rules as circumstances
warrant.


> As for this particular argument about which is better, I will not
> respond to any further bait.

"This is my opinion, and I don't want to hear yours."  Ah well, you should
know better, I'm going to give my opinion anyway.