rob@xxxxxxxxx wrote:
Why does it drive you bonkers to put any constraints and triggers on the database? Why do you insist it be ONLY in the application (or some database wrapper)?
Not against it at all. I think Tommy expressed it very well - regardless of how many constraints and triggers and hoohahs and geegaws you have, there should be no program putting bad data into your system. Your applications should check all conditions prior to writing to the database. It's a philosophy thing.

So, if your various database artifacts are purely a backstop as opposed to your primary gateway for validation, I have no problem with them.


And it would be glorious if applications never had an error,
If no one ever hacked into data for malicious purposes,
And if no one ever made a keying error when using a database utility
And if no one ever had a need, or use, for UPDDTA, WRKDBF, or such utilities.
But everyone joining hands and singing "Kumbaya" is not going to make it so.
Therefore journalling, constraints and other tools should be used.

Again, it's a matter of philosophy. For the situations you portray, most of these tools are after the fact propositions; they may tell you what happened, but they don't prevent them from happening. If your production database is open to hacking, you have much bigger issues than simple journaling will help with. Likewise if you're using DFU on production data. The same with ODBC access.

So, if you have bad things happening to your data regularly, then journaling and triggers and whatnot are a good thing. If you have a more disciplined approach to production data management, then they're less needed. Not necessarily not needed, just less. And this isn't saying your approach is bad Rob, just that I advocate a slightly different focus: on avoiding the causes of bad data in production.

What I have a problem with is the notion that anybody who doesn't use these things is backwards. It's simply not true. The use of each and every database technique - from ISAM to SQL, from servers to ODBC, from triggers to constraints to journaling, from mirroring to RAID to ASPs to HA - is a business decision and it depends on your specific situation.

The other thing I don't like is using RI, constrains and triggers as a replacement for application-level editing. Now this is purely a personal issue, but I don't like having business logic in a bunch of different places (some in RI rules, some in constraints, some in triggers, some in the application). But I'm not dead set against it. In fact, thinking about it, there's no reason you couldn't encapsulate your edits, use them first in your application program, and then reuse them in your triggers; that way, they'd perform both purposes. But I digress.

My major issue: just because someone doesn't use the database the way you do, Rob, doesn't mean they're backwards or out of date or whatever. There are sound business reasons to use or not use each of these capabilities.

In fact, I think I've recognized a primary philosophical difference between you and I. You don't trust your programmers or your applications. I assume that you, Rob, are the arbiter of the constraints and so on that go on the database. That gives you control over the data regardless of what the programmers and users do. And in that case, I can see why you would want that control, and for others whose environment mirrors yours, it's a perfectly sound business case. For people who have tighter control over their production environment, such database-level control might not be necessary.

I don't want to argue about this anymore. If you're willing to agree that not everybody needs the same database controls you do, then we're cool. If not, then we disagree. In either case, this horse is pretty dead.

Joe

This thread ...

Follow-Ups:
Replies:

Follow On AppleNews
Return to Archive home page | Return to MIDRANGE.COM home page

This mailing list archive is Copyright 1997-2020 by midrange.com and David Gibbs as a compilation work. Use of the archive is restricted to research of a business or technical nature. Any other uses are prohibited. Full details are available on our policy page. If you have questions about this, please contact [javascript protected email address].