> "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.