That the integrity of data should be maintained is of no question, where the
responsibility for enforcing that integrity lies is a question.  I, for one,
can see that if the content of some fields (dates, times, and the like) were
enforced at the DBMS level, it would make the coding part easier.


        -----Original Message-----
        From:   Steve Dirickson [SMTP:[log in to unmask]]
        Sent:   Thursday, March 08, 2001 12:39 PM
        To:     [log in to unmask]
        Subject:        Re: 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.