----- Original Message -----
From: "Steve Dirickson" <[log in to unmask]>
To: <[log in to unmask]>
Sent: Thursday, March 08, 2001 1:38 PM
Subject: Re: [HP3000-L] Expensive RDBM Systems (Oracle)


> > "Input masking, value limits, non-structural data
> > validation"
> >
> > > These are functions of a data entry application, NOT a dbms.
>
> I think Fred used to phrase it along the lines of "IMAGE is a DBMS, not a
> data management system."
>
> It was a cop-out when I first heard it years ago, and it's still a cop-out
> today. Validated data, enforced types, engine-guaranteed logical
integrity,
> and similar concepts are just as much an integral part of the "base data"
of
> an application as are the size of the "Order Number" field or the link
from
> an invoice number to the associated payment. If my data system allows me
to
> delete the record defining an inventory item while there are still
> outstanding orders asking for that item, that system has failed in one of
> its primary responsibilities. If it lets me enter "78 March 2001" into a
> date field (an easy "fat finger" typo for today's date), it hasn't done
its
> job.
>
> The usual response is that "business rules like those belong in the
> application, not in the DBMS." Wrong again, for a simple reason: these
> aren't business rules; they're data-integrity constraints. They must be
> enforced no matter what happens to be used to access the data. Something
> like "New orders from customers with more than three unpaid invoices will
be
> put into 'Pending' status and will not be processed until at least one
> payment is received" is a business rule, and it's fine to put it in the
> middle or front layer. If the system allows an order to be entered via a
> non-standard path that doesn't enforce the rule, it may cause an
> inconvenience (or a termination of someone's employment), but the
integrity
> of the company's data is maintained. In contrast, data-integrity
constraints
> must be honored in all cases, and they can only be guaranteed if they are
> active no matter what the access path, which means that they have to live
in
> (or very close to) the same place as the data: the DBMS.

Amen!

Nick D.