Re: Dropping ACID - was Re: does a table always need a PK?

After takin a swig o' Arrakan spice grog, Jonathan Leffler <jleffler_at_earthlink.net> belched out...:
> Christopher Browne wrote:
>
>> Alfredo Novoa <alfredo_at_ncs.es> wrote:
>>>BTW, does anybody knows if Date and Darwen are considering to drop
>>>transactions in the next revision?
>> Drop them? Or "drop them into the book"; they only made limited
>> comment about them in the last revision. (Which doesn't imply that
>> transactions are irrelevant, just that they weren't relevant to the
>> points they were trying to make about relational databases.)
>
> Drop them is the question - see the comments in Date's 8th Edition
> (Section 16.10 - Dropping ACID).
>
> I don't know is my answer - but maybe. Of course, the replacement is
> the 'multiple assignment' operation (including multiple insert or
> delete or update operations), and it has a number of attractions. I
> would certainly love to have that available. I'm not sure how much
> you need transactions if you have 'multiple assignment'; nevertheless,
> at the moment, I think I still like the idea of nested transactions. I
> need to re-reread the material cited.

Very interesting.

I haven't a handy copy of _Date_, as the local libraries aren't big on high end texts.

That is a _very_ curious proposal; it surely bears some comment.

It would be most ironic if relational databases got around to dropping ACID just when the MySQL people try to get their implementation mature. :-)

The issue of how strongly concurrent transactions need to be like their serialized alternatives certainly pokes at there being some imperfections to the notion of ACID. It will take a good deal more than that to satisfactorily justify it being a good idea to drop ACID altogether.

-- 
(format nil "~S_at_~S" "cbbrowne" "ntlug.org")
http://www3.sympatico.ca/cbbrowne/spreadsheets.html
"Anyone who says you can have a lot of widely dispersed people hack 
away on a complicated piece of code and avoid total anarchy has never 
managed a software project."  Andrew Tanenbaum, 1992.