Re: Concurrency in an RDB

Bob Badour wrote:
> 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.

That seems like a tautology. Obviously the enforced integrity constraints should always be enforced. The question for me is: should the (enforced) integrity constraints be strong or weak? What are the pros and cons of having separate verification queries?

> However, that does not mean the
> dbms must evaluate huge numbers of expensive operations every time
> anything changes in the database.

That depends on the nature of the integrity constraint.

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

That minimal set may be computationally expensive.

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

Seems like another tautology. Obviously once you've decided what's necessary you will implement accordingly. Let's discuss what's actually necessary!

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

That's a good characterisation of an RDB. Not particularly relevant to a DB used to store the content for a newspaper.

Source code developers, digital circuit designers and CAD draftsmen all use tools that don't enforce (strong) integrity constraints as they edit the data. This doesn't seem to hamper them.

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

I agree that can be useful. It depends on the application.

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

Cheers,
David Received on Sun Dec 24 2006 - 02:37:10 CET