Re: Transactions: good or bad?

From: Todd Bandrowsky <anakin_at_unitedsoftworks.com>
Date: 7 May 2003 16:01:02 -0700
Message-ID: <af3d9224.0305071501.4eccbed5_at_posting.google.com>


>
> You'll have to point me to where I have argued against serialization. I can't
> recall that I have.

I seem to have inferred from your posts that transactions were not good because they do not properly follow the "arrow of time". Yet, transactions are part and parcel rooted in serialization theory, so I'm not really sure what you are after!

:-)

> So your argument in favour of transactions is so that an application can
> maintain derived data?
> You are thinking way too low level.
>

It's a habit of mine! :-)

> If a database has some user visible derived data (such as a total), then that
> derived data will be constrained to be the value of the derivation. If it is
> not so constrained, then as far as the database is concerned, it is not
> derived data. Now, any update to the 'base' data will have to be combined with
> an atomic update to the derived data. This is simply done (in my logical
> scheme) by a single update to the value of the database. Transactions (besides
> stuff to support consistency in the face of system errors) don't get a look
> in.

But that implementation requires a transaction, does it not? In your case, you have, two users writing a change to the base data, then, both want to take the results and re-update the underlying data. To do that means some sort of synchronization, locking, etc, At least, internally.

As soon as you that "Atomic word", all sorts of rules kick in. It means transaction, it means concurrency control. So, what's the real advantage. I mean, you are either surfacing a transaction to the user or doing it under the covers and I don't know how that buys you much, except for the convenience to the user.

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.

>
> [snip]
> > >
> > > Semantic optimisation is a general ability of any well implemented RDMBS.
> >
> > Yes, but you have to implement that RDBMS on top of a server first.
>
> You are confusing databases with DBMSes.

No, not at all. Blink. I meant what I said. Instead of having a database / concurrency engine that uses a SQL language, I have a database / concurrency engine that uses a domain specific language.

> I'm all in favour of people selling
> databases (assuming that Intellectual Properties issues - i.e. stopping people
> ripping off your database - are fixable). Such sold databases would be
> application/business domain specific but would all run on a standard, generic
> business RDBMSes.

Nope. Why have the middleman and the additional complexity? RDBMs are designed to be general purpose instruments and I don't think in any walk of engineering is a case where a general purpose instrument long survives in the face of more specific components. Simply plopping a schema on top of them is nice, but, the whole lot is so complex, and the underlying logic of transactions and file management and index handling, so well understood, that, if the domain is in the sweet spot, I would say you wouldn't need that swiss army knife to support a product. Received on Thu May 08 2003 - 01:01:02 CEST

Original text of this message