Re: Concurrency in an RDB

From: Bob Badour <bbadour_at_pei.sympatico.ca>
Date: Sat, 23 Dec 2006 17:02:48 GMT
Message-ID: <Yidjh.36685$cz.539574_at_ursa-nb00s0.nbnet.nb.ca>


Marshall wrote:

> On Dec 22, 4:52 pm, "David" <davi..._at_iinet.net.au> wrote:
>

>>I've said many times in this thread that complex integrity constraints
>>can and should be enforced indirectly through separate
>>validation/verification queries.  Here are some examples where that
>>approach is already used in today's applications
>>
>>1.   Source code compilation
>>2.   Software unit testing
>>3.   VLSI chip layout constraints
>>4.   Digital circuit verification
>>5.   Finite element modelling verification
>>6.   Geometric model verification
>>
>>Surely you agree these sorts of constraints shouldn't be enforced on
>>every update to the DB?

If the integrity of the database requires them, then the dbms must enforce the constraints at all times. However, that does not mean the dbms must evaluate huge numbers of expensive operations every time anything changes in the database.

As it happens, relations and functional dependencies provide the means for the dbms itself to calculate the minimal set of constraints necessary to evaluate to guarantee integrity. Normalization helps minimize the number and complexity of dependencies thereby facilitating this process.

> I'm not sure if this is a trivial rephrasing of what you just
> said or an actual disagreement, but no, I would not agree
> that they "shouldn't" be enforced on every update.
> However I would agree that there may be practical limitations
> on so doing, such as the amount of time necessary to check
> the constraint. Any constraint that can practically be checked
> on every update should be.

I disagree with that last sentence. The dbms should not evaluate any more constraints than necessary regardless of cost. Neither should it evaluate any fewer.

>>I have the impression (please correct me if I'm wrong) that your
>>assumption that a DB should always be in a valid state is coloured by
>>the (relational) problems that you have expertise in.

Sigh. Regardless of the logical data model, a dbms is a formal logic system. The folks who spend money to build databases expect some return for their investment in the form of correct and useful answers.

For the formal logic system to deliver correct answers, the database must record the correct facts, and the manipulation function must operate correctly. The integrity function is the principal means to achieve this end.

> Certainly this is always true for everyone. However I am having
> a hard time seeing the value of your approach given how much
> less it lets us count on the dbms. I'm also unclear on how much
> I have to give up in the way of integrity enforcement. I'm having
> a hard time building a mental model for that. Your intent only to
> speak at a high level somewhat exacerbates this difficulty.
>
> Hmm, I just had an interesting idea. Perhaps the issues your
> idea raises could be dealt with as a "quality of service" issue.
> Where one needs strict durability, one could so specify externally
> to the application.
>
> This is a bit tricky because of the question of guarantees of
> desirable properties. One area I'm interested in is
> static analysis, and that's entirely dependent on building
> theorems from known properties of a system. Weakening
> those properties might render some analysis techniques
> unsound.

Indeed. Received on Sat Dec 23 2006 - 18:02:48 CET

Original text of this message