Re: Transactions: good or bad?

"Todd Bandrowsky" <anakin_at_unitedsoftworks.com> wrote in message news:af3d9224.0305101732.631f6084_at_posting.google.com...
> <snip>
>
> > All the optimisations in the world fail in the face of badly or
maliciously
> > coded user transactions.
>
> I agree.

Good.

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

Agreed.

> 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

I allow no rollbacks in my model (short of system failures)

> or the nasty locking of the database.

My locks are exposed. They are part of the business rules of any particular database. Unlike today, they are not 'nasty'.

> Worst of all, you won't
> --really-- solve the problem of users defining transaction lengths.

Why not?

> They will still be able to do with sufficiently complex statements.

I would only give the untrustworthy statements of 'limited' power. No generalised transitive closure for example. Also, business rules about the maximum cost (in space and time) of a given atomic statement (as calculated by the query optimiser) for each user can be enforced.

> The logical model doesn't really solve the problems as much as it
> sweeps them under the rug!

Wrong. Some aspects are exposed. Locks are made visible as plain old relational data. Other aspects, such as long running atomic statements, are minimised (or are minimizable with the extra optimisation opportunities afforded)

> > > 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:
>
> a) 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.

"people much smarter than we". Now that's verging on another logical fallacy. First, how do you know how smart I am, or how smart you are for that matter. Seconds, smarts come in many varieties and can only really be allocated after the event. Heck, maybe I am a genius (although I would not stake much money on it). But it's not for me to decide.

"figure out a way of restating our problem so that we don't need serialization in the same way we need it now."

Maybe that is what I am doing. We do need serialization, but we don't need it in the face of user transactions because we don't need user transactions.

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

You think?

> It costs too much money to turn it into something
> real.

How many man hours have Alphora spent I wonder? Not many in the big scheme of things. They are a very small company (so far) and they have the most complete, most real implementaion of the relaitonal model so far.

> Could any database internally implement the relational model?

What do you mean by 'internally implement'? IT IS A LOGICAL MODEL, it does not matter how it is implemented just as long as the implementation 'simulates' the model 100%.

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

Life is about finding the most appropriate levels of abstraction. The relational model is great at the level of centralised, application independent, corporate wide data description and manipulation.

> But we don't.
> And we shouldn't do the same with databases either.

The relational model, certainly a broad, practical exposition of it such as characterised by Date and Darwen, is at a much higher abstraction level than say Turing machine. It is at just the right level of abstraction in my opinon.

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

confuscated ?

Dictionaries fails me.

Regards
Paul Vernon
Business Intelligence, IBM Global Services Received on Mon May 12 2003 - 12:46:17 CEST