Re: The Practical Benefits of the Relational Model

In article <aok5dt$16tm$1_at_sp15at20.hursley.ibm.com>,

Paul Vernon <paul.vernon_at_ukk.ibmm.comm> wrote:

Well, the RM doesn't speak about how to deal with concurrency problems, so it doesn't really require anything at all in that respect.

> The only things they provide that
>cannot be done using core model concepts, are things that explicitly do not
>want to be in the hands of users.

What they provide is the illusion that you are the only one who is allowed to use the database at the moment and everybody else has to wait. I have yet to meet the first student of mine who cannot get her or his head around that.

>I'm thinking of integration with external
>systems. E.g.
>
>BEGIN TRANSACTION;
>UPDATE account SET balance = balance + £500;
><message external system>
>IF fail then ROLLBACK
>ELSE COMMIT
>;
>
>Now, if a *user* is exposed to that, then the less trustworthy user could
>just go:
>
>BEGIN TRANSACTION;
>UPDATE account SET balance = balance + £500;
><message external system>
>IF fail then COMMIT
>ELSE COMMIT
>;

This user apparently wouldn't be able to understand a simple text editor that has a save function and an undo function. I'm not sure if such people should be writing database transactions.

>> In theory all the user needs to know is that the transaction begins at
>> some point, ends at some point and sometimes the user or the database can
>> decide to undo everything that was done since the beginning of the
>> transaction.
>
>Plus strange ideas like that a user can see their own uncommitted data but
>other users cannot,

That's because they have to wait until you are done. :-)

>that constraints may (or may not?) be deferred to commit
>time,

That is not intrinsic in the transaction concept. That constraints are usually checked before the end of the transaction has more to do with implementation efficiency.

>that triggers may (or may not) fire until commit,

Triggers are problematic anyway and also this is not an intrinsic part of transactions. You could for example prescribe that triggers are always fired at the end of the transaction.

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

> that nested transactions are possible and rollbacks might only undo back
>one level of nesting, etc, etc

The original transaction concept excludes such a thing as nested transactions.

>> The "damaging" complexity rears its ugly head when you start talking
>> about implementations in practice that do not offer full serializability
>> or explicit locking.
>
>Explicit locks should be seen as just constraints that don't tend to exist
>for long. Agree?

I'm not sure what you mean with "should be seen as just constraints".

>>But these are in some sense implementation issues.
>
>In what sense?

In the sense that the simple concepts of transaction and serializability are tampered with to improve efficiency.

• Jan Hidders