Re: Pizza Example

From: Jerry Gitomer <jgitomer_at_erols.com>
Date: Tue, 06 Apr 2004 10:19:45 -0400
Message-Id: <pan.2004.04.06.14.19.44.379230_at_erols.com>


On Tue, 06 Apr 2004 05:01:24 -0700, Tony wrote:

> Jerry Gitomer <jgitomer_at_erols.com> wrote in message
> news:<
pan.2004.04.06.05.00.25.384317_at_erols.com>...
>> On Mon, 05 Apr 2004 11:19:56 -0500, Dawn M. Wolthuis wrote:
>>
>>
>> [snip]
>> > What I have seen with RDBMS's is that the size constraint is placed on
>> > everything while more important constraints related to the allowable
>> > values are not as often applied, especially when it is a "yellow flag"
>> > type of data value for an attribute rather than obviously not
>> > permitted. I'll put this in a separate thread at some point (but have
>> > several other questions prior to that one).
>> >
>> >
>> I prefer that the "more important constraints" be handled by the
>> application programs rather than incorporated into the RDBMS. This is
>> because the application programs are specified and written by developers
>> and analysts who are working with the users and have first hand
>> knowledge of the business rules while the database is cared for by the
>> DBAs who are concerned with the efficiency and effectiveness of the
>> database in meeting the needs of many different applications.
>
> I was agreeing with your post right up to this bit. Yes, the database is
> cared for by DBAs, but the constraints are specified by analysts and
> written by database designers (who may or may not also be the DBAs). The
> very fact that the database meets the needs of many applications is the
> reason for handling "more important constraints" (especially) in the DBMS.
> Otherwise the DBMS is just a glorified file system, not a Database
> Management System.
>

We disagree on this point. My own opinion is based on my experience where I was responsible for 12 production databases supporting literally thousands of application programs. Neither I nor my junior DBAs had the time to become familiar with the requirements of the various applications we were supporting. Under these conditions I felt that it was necessary for the analysts and developers doing the applications to design and implement the validation procedures in their programs. My understanding with the analysts and developers was that if they gave me good data to store in the database I would guarantee that it stayed good and would be available without change or modification until scheduled for deletion.

> It is true that current SQL products don't allow you to enforce all
> constraints declaratively, and that's a great pity. In an ideal RDBMS
> the user should be able (theoretically) to fire DML statements directly
> at the database and be sure of violating no integrity or security rules;
> the application is then just a way of making that task (much) easier.
> With current SQL products the best you can do is protect your tables
> behind stored procedures that encapsulate the rules that can't be done
> declaratively; still, that keeps the user-interfacing application(s)
> free of responsibility for enforcing business rules.

I think a balance must be struck between adding capabilities to the DBMS and "cowboy coding". The extensive use of stored procedures to perform validation is, in my opinion, a good balance. It offers the infrastructure people (the DBA and senior analysts and developers) the opportunity to control the code while offering the development community proven and tested reusable functionality. That being the case why should we add unnecesssary complexity to an already too complex product (the DBMS)?

Jerry Received on Tue Apr 06 2004 - 16:19:45 CEST

Original text of this message