Re: The Practical Benefits of the Relational Model

"Jan.Hidders" <hidders_at_hcoss.uia.ac.be> wrote in message news:3db0b70e_at_news.uia.ac.be...
>>Could you point me in the direction of such protocols?
>
> See for example 'timestamp-based concurrency control' in Ullman's
Principles.

Thanks.

[snip]
> conflicts. The only way to avoid [transaction sabotage] is by not letting
the database
> guarantee anything about whether the values you just read are still valid or
> not when you commit your writes.

I would say:

The only way to avoid transaction sabotage is by not letting the *DMBS* guarantee anything about whether the values you just read are still valid.

Database constraints (often with a temporal component) can be used by users (when allowed by the database design) to create guarantees about whether values just read are still valid. Such a constraint based approach not only exposes all 'locks' as relational data, but also allows different relvars (and sets of relvars) within a database to have different locking 'protocols' implemented. It is my position that locking is a database design issue rather than a DBMS 'feature'.

[snipped-in]
>>that rolled back data vanishes and can only be audited outside of the model
>>(so breaking the information principle),
>
>That's like complaining that if you undo something in Word the document
>doesn't show the edits that were undone. That's the whole point of the undo!

Yes, but note carefully. In word undone changes explicitly do not vanish. You can always *redo* them. Word even saves the undo/redo data with the document so that you can redo from a newly opened document.

In other words, the 'log' is exposed as part of the users conceptual model. Both in the undo/redo feature, but more explicitly in the 'track changes' feature. Are you suggesting that the database log should be exposed as part of a database user's conceptual model?

Regards
Paul Vernon
Business Intelligence, IBM Global Services Received on Mon Oct 21 2002 - 11:55:02 CEST