Re: Pizza Example

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

This is a working method that I do recognise and think of as practical. But I do not know how you can guarantee that the data would be 'correct'.

I am hinting at situations where two (or more) concurrent users do a database modification were both do not conflict with the database but do conflict with eachother.

Because the designing and checking is done by both members of the application team, the check can be 'correct' the mutation can be 'correct' but two mutations (not seeing eachother) can be 'wrong'. For example making a new entry in the appointment table. Application wants to insert an appointment, checks if it conflicts with any existing appointment and does the insert. Other application does the same at approximately the same time. (Some databases do allow for this kind of behavior). Which results in a overlapping oppointment.

Or am I wrong in this ?

ben brugman Received on Thu Apr 08 2004 - 14:03:05 CEST