Re: Trigger programme without a trigger.

CRPence wrote:

And so it is very true, that the same concern exists as an issue with the database trigger, e.g. some result is not to the satisfaction of the implementor, so when they find the trigger they CHGPFTRG to disable it while they do their magic to correct the data. However in the case of either CHGPFTRG or RMVPFTRG, the implementor should at least *know* they are bypassing the business rules. That as compared to accidentally [not "accidentally"] bypassing the business rules, which is much more likely to occur with I/O access control established outside the database. The trigger is visible, whereas an application as expected arbiter to the I/O is not so plainly obvious. The trigger can be found and subverted, but even overlooked, it is still enforced. However the application as arbiter may be easily overlooked as a result of either human error or negligence, and overlooked, it will not be enforced.

I'll disagree once more just to reiterate my point, and then move on.

It is no more likely to accidentally get around high-security access profile than it is to accidentally remove a trigger. Both require subverting security policies which *should* be incapable of being subverted. Otherwise, they're really not security policies. That either one could happen is an abject failure of the system.

Remember, I'm talking about a specific architecture in which the database can only be accessed through a specific user profile. Subverting that requires an security breach as egregious as that which would allow removing a trigger. A properly deployed security system prevents both. Improperly deployed security prevents neither.

So, in the end, the data protection aspect of trigger vs. I/O module is moot: both work exactly the same, and both depend on a properly deployed security policy. And thus the choice between the two should come down to an application-driven business decision.

This is simple stuff. Rather than designing systems based on theoretical security lapses, you should instead deploy your systems correctly. If you disagree, then fine. I can leave it at that. But it's a fallacious argument to say that triggers protect data any better than HSA profiles.

Joe