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
midrange.com
