Re: Requirements for update languages?

"Jens Lechtenboerger" <lechtej_at_uni-muenster.de> wrote in message news:ea859e4e.0211140628.8694f17_at_posting.google.com...
> hidders_at_REMOVE.THIS.uia.ua.ac.be (Jan Hidders) wrote in message
> news:<3dcde82e$1_at_news.uia.ac.be>...
> > I don't
> > think there is really such a big difference between the database computing
> > some extra updates after you have committed and another user that bases
some
> > of his or her updates on the data you committed.
>
> I see a difference. If *the database* does additional updates, then
> those updates are executed within *my* transaction and *I* feel
> responsible for my transactions. I don't feel respnsible for
> transactions of other users.

Absolutely.

I believe that both users and the DBMS have *rights and responsibilities*, but that this has been overlooked by database theory.

If we want to remove the application layer, and assuming that computer science is truly trying to follow a 'complexity reducing program' as Papadimitriou mentioned in http://www.cs.berkeley.edu/~christos/pods95.ps (thanks for the link Lauri) such a removal would surly be a laudable goal. Then the application layer's role of trusted intermediary needs to be replaced with a direct mutual trust between Users and DBMS.

Users should be able to trust the DMBS to do what they tell it and nothing else. To trust that the DMBS be honest, fair and equable.

The DBMS should trust the users to be Human. E.g. To trust them to be self interested and fallible, to be suspicious, to explore and then push the boundaries, to learn slowly as the beginning but sharply later and to give respect and trust back to the DBMS when it is deserved.

For the point in hand, if a DBMS wants to do additional updates, then it must either explicitly or implicitly *ask the user for permission* and be open about what it is doing.

Or, to put it in more usual terminology, 'additional database executed updates' should be seen as a *part of * the users transaction and be *visible* as part those transactions. As an example, see my post some time ago on how referential actions (like 'on delete cascade') should be seen as part of the macro expansion of statements such as DELETE.

Regards
Paul Vernon
Business Intelligence, IBM Global Services Received on Thu Nov 14 2002 - 23:59:16 CET