Re: The Practical Benefits of the Relational Model

"Paul Vernon" <paul.vernon_at_ukk.ibmm.comm> wrote in message news:<aq3r28$k8a$3_at_sp15at20.hursley.ibm.com>...
> Come on Paul, keep with the program. ;-)

  It's been a big program.

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

   Well, it seem to me that all you've done is to redefine a 'multi-statement   transaction' as something called a 'multiple assignment statement', and   thereby to abolish the term 'transaction' from the data language. Which seems   completely reasonable. You say 'tomato', I'll say 'tomato'. If the point boils   down to how you use a semi-colon I have no argument.

   But (lucky for me) implementing 'multi-assignment operators' will still   require all of the considerable body of theory (dependency graphs) and   engineering practice (locking structures, logging, recovery, blah blah blah)   I've been working with.

    I dunno. I guess I don't see a logical difference here.

    What can be done with 'multiple assignment operators' that cannot be   done with explicit transaction boundaries? (Or should I just get with the   program a bit more?)

    KR

             Pb Received on Mon Nov 04 2002 - 05:27:33 CET