Re: Transactions: good or bad?

<snip>

> All the optimisations in the world fail in the face of badly or maliciously
> coded user transactions.

I agree.

>
> 1) Removing the concept of transactions from the Logical Relational Data
> Model. It is unnecessacary, redundant and harmful. We were "sold a bill of
> goods" back in the day. We should get rid of them now.
>
> 2) A Logical Relational Data Model that is thus, cleaner, more powerful and
> can provide for complete independence of databases from applications.
>
> At least internally. Yes. Internally you can use whatever you like to ensure
> consistency. I have been at pains to point out that I'm not against
> transactions per se, just those exposed in the Logical Data Model.

1 and 2 sound promising, but, in order to implement, you will need to have transactions internally, even if they are not exposed to the end user. As a result you will wind up a database server that still suffers from the same dramatic compromises and failures that today's database servers have. You will either have the cascading rollbacks of MVCC or the nasty locking of the database. Worst of all, you won't --really-- solve the problem of users defining transaction lengths. They will still be able to do with sufficiently complex statements. The logical model doesn't really solve the problems as much as it sweeps them under the rug!

> > The only way, that I see, to really avoid transactions and have
> > maximum concurrency is to not allow derived data to be stored at all.
>
> Like the fact that if you have a single CPU, then a single instruction is
> sterilised by definition? So as long as every database action is a single CPU
> cycle, then you get maximum concurrency?

Were that were true, that would be nice, but, again, I think even if it were a single CPU instruction, it would be one whose executation time was unbounded and so instead of having a database server that periodically rollsback and deadlocks, you would have a chip that did the same.

There's really two ways to fix transactions:

1. devise some newer better more clever algorithm for concurrency and serialization.

or

b) devise a different approach that produces as good as or better results, but does not demand serialization.

So, we can either think up a brilliant new algorithm for concurrency control, which many people much smarter than we are working on with little success, or figure out a way of restating our problem so that we don't need serialization in the same way we need it now. I think the latter way is more promising.

>
> Additional complexity!!! What, compared to thousands of application specific
> DBMSes?

It wouldn't be thousands of application specific DBMSs, probably a market space of about maybe a dozen or so. Many different applications do the same kind of thing over and over again. Ten different kinds of power, gas, water, etc, measuring and billing applications, etc, could all use one kind of database.

>
> Now I do understand your argument.

See above.

> All things being equal, a specific tool will out perform a general purpose
> tool
>
> But all things are never equal. The general purpose tool has the economic of
> scale - you can sell more so can invest more in the design and development of
> the tool.

Given the investment required to get anything useful out of a general purpose tool, I should think these vendors are nothing more than gigantic targets.

>
> Maybe SQL is too ill fitting. The relational model itself is not.

The relational model is too broad and too vague to solve any real business problems. It costs too much money to turn it into something real. Could any database internally implement the relational model? Absolutely! If the utility of a solution is weighed by its generality, then we should perhaps just give our customers Turing machine simulators and then tell them to have at it. But we don't. And we shouldn't do the same with databases either.

It's time to put SQL and the Relational Model back into the Universities and Software development companies where they belong, and take all of that overly confuscated crap out of our trading desks and factory floors. Received on Sun May 11 2003 - 03:32:16 CEST