Re: The Practical Benefits of the Relational Model

Come on Paul, keep with the program. ;-)

Earlier in this thread

>"Lauri Pietarinen" <lauri.pietarinen_at_atbusiness.com> wrote in message
news:3DAC627B.813F603C_at_atbusiness.com...
>> What do you have in mind for replacing the functionality of transactions?

and I replied

>Multiple assignment, or more correctly dbvar assignment.
> (dbvar = [the] database variable)

>Plus the use of local/temporary/database relvars to allow sets of data can
>be built up over time, then be added to the 'main' database in one single
>multiple assignment.

>Plus any 'locking' functionality required via database constraints.

So, the short answer to your example is

    INSERT INTO Emps VALUES ( 1, "Me" ),     INSERT INTO Works_For (Emp, Dept, Start ) VALUES ( 1, 1, TODAY );

Which is a single atomic statement - a 'multiple assignment' in Date & Darwen's
terminology.
As it happens I'ld prefer to talk in terms of database variable assignment, but the above syntax surfices for current puroses.

> All of your examples, Paul, talk about Isolation and Consistency of a
> single query but Atomicity and Durability are also part and parcel of the
> transaction concept.

BTW I don't think that ACID per se, brings much to the party.

Atomicity. Yes, and one reason I don't like transactions is that in some sense they are not atomic, they do have parts, and with the user being able to pause between those parts, a transaction is not *atomic in time*.

Consistency. Ok, but who would want an inconsistent database anyway? And what we are really talking about here are constraints.

Isolation. I say that if you have true atomicity, then you get isolation by default.

Durability. Yes, but that's by definition (part of) the concept of a database. And
the word 'persistent' captures the meaning better IMO.

(P.S. If we want to debate on ACID specifically, lets start a new thread)

> Having a mechanism to specify the boundaries of a unit of work
> (after which the database must be consistent) is necessary
> in most business applications.

I'm yet to be presented with a single example of why transactions aka unit of work boundaries (greater than a single statement) are required. Going back to my previous reply to Jan, I guess I should be able to *prove* my claim, but (as I think I've admitted before), I've never been very good at formal proofs.

It seems obvious that with 'multiple assignment' we can set a database to any valid value. My only doubt is that there is something about the semantics of transactions that cannot be replicated by database constraints. Except for interactions with external systems, which I rule out of consideration here by my definition of what a database *user* is, I can still see no requirement for transactions.

> Call it what you will, but the concept of a 'user-specified unit of work'
> seems to me to be a necessary feature of any data language. At points
> within a multi-query operation the database can be inconsistent, but not
> at the end.

In my scheme this is not an issue as I would not allow 'user-specified units of work'.

I will note that in the 2nd edition of the manifesto Date & Darwen only allow "immediate checking" of constraints, commenting (in a note on page 178) that:

   'Deferred checking opens the door to numerous problems'

And I agree with them here, I just would like to see them go further and straight reject transations.

Regards
Paul Vernon
Business Intelligence, IBM Global Services Received on Sun Nov 03 2002 - 18:45:55 CET