Re^2: [Semi-OT] Views, Stored Procedures, and Class::DBI

Triggers ... My opinion is that if you are depending on them, you either don't trust your programmers or you build it wrong.

You say it like that's a bad thing. :-)

There are times when you really don't want to trust programmers. For instance one common use of triggers is for auditing changes. You don't want to be in a position of having a change in your financial data that you can't explain. Depending on your database (I've seen it demonstrated with Oracle), it is possible to set things up so that nobody - including the DBA - can make a change without it being audited. Sure, you can turn auditing off. But the fact that you turned it off will itself get logged.

Usually this would be overkill. But there are situations where you really do need to be able to trust, but verify to this level.

Comment on Re^2: [Semi-OT] Views, Stored Procedures, and Class::DBI

Replies are listed 'Best First'.
Re^3: [Semi-OT] Views, Stored Procedures, and Class::DBI by mescanne (Sexton) on Oct 19, 2005 at 12:16 UTC
I think you have it exactly right, but I'd like to expand on the example. Imagine an organization that has a sizeable group in charge solely of the database -- including replication across many servers, rational backup schemes, auditing and authorizing changes, optimizing queries and maintaining performance, etc. -- and then a wide variety of other groups which both develop applications as well as users using a variety of SQL reporting tools. The entire exercise can get exceedingly complicated and it can be pretty clear how triggers and stored procedures can be immensely useful for the DB group to maintain control. From a one database to one application relationship these tools don't seem to make as much sense. Mark	[reply]
Re^3: [Semi-OT] Views, Stored Procedures, and Class::DBI by dragonchild (Archbishop) on Oct 19, 2005 at 13:18 UTC
You say it like that's a bad thing. :-) grins It's not a bad thing. In fact, it's often the only recourse a DBA has, precisely for the kind of reason you're talking about. My criteria for good software: Does it work? Can someone else come in, make a change, and be reasonably certain no bugs were introduced?	[reply]