Re: How widespread is the use of triggers these days and how concerned about performance?....

I have been teaching Database Design and administration (for a major vendor) and a working, hands-on DBA for 20+ years. One thing I have learned and tried to pass on to my students is that ultimately "the buck stops here." It does not matter that a programmer's faulty logic or the careless use of an interactive SQL tool corrupted the database, it's the DBA's fault for not preventing it from happening.

The average DBA can not enforce programming standards or review code - time and policy usually will not allow it. And today's databases are updated from a multitude of sources outside the immediate control of the server and the DBA. I have seen production databases destroyed by end users and an Excel spreadsheet because by policy update rights were not removed. And what DBA hasn't taken the rap for poor application performance?

Where mainframe based OLTP platforms managed problems such as deadlocks and rollbacks, the client-server DBMS systems of today leave much of those issues to the programmer to design, program, and react to. And let me ask - have you ever met a programmer who really understood concurrency?

So, to me, triggers, check constraints, and referential integrity become the last bastion of control. I do not wish to do a programmer's job for him and I consider many of the UDF's, Stored Procedures, and even triggers issues that could and should be handled at the program level. But to paraphrase the marketing slogan for an overnight delivery company: When it absolutely, positively got to be done .... Received on Mon Aug 04 2003 - 09:41:44 CDT