Re: The Practical Benefits of the Relational Model

"Jan.Hidders" <hidders_at_hcoss.uia.ac.be> wrote in message news:3dad4bb6$1_at_news.uia.ac.be...
> It's not the transaction concept itself that is complex.

Well 'complex' is relative. What matters is that it consists of a number of concepts (such as commits, uncommitted transactions, rollback etc) that are not required in the relational model. 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. 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
;

> 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 constraints may (or may not?) be deferred to commit time, that triggers may (or may not) fire until commit, that rolled back data vanishes and can only be audited outside of the model (so breaking the information principle), that nested transactions are possible and rollbacks might only undo back one level of nesting, etc, etc

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

>But these are in some sense implementation issues.

In what sense?

> That doesn't mean they are unimportant (on the contrary) but it does
> mean that it is not the theoretical model that should be changed.

Even if you could persuade me that it is only poor implementations that are "damaging", not transactions in the model itself, I would still contend that transactions give users more ways of doing the same thing, which (Perl excepted) is generally a (very) bad thing.

Regards
Paul Vernon
Business Intelligence, IBM Global Services Received on Wed Oct 16 2002 - 18:50:30 CEST