Re: Transactions: good or bad?

"tj bandrowsky" <anakin_at_unitedsoftworks.com> wrote in message news:af3d9224.0305061606.48d5daae_at_posting.google.com...
> >
> > You go for it Todd.
>
> Ok, on one side, you are arguing against serialization, and on this
> thread, for.

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

> You must be either ornery or have a viewpoint of some
> sophistication, and in either case, I'll bite.

Wow, had to look that up in the thesaurus. Wilful, rebellious? Me? No, just after the Truth.

> How transactions may not be necessary
> -------------------------------------
> I imagine you might be able to dispense with transactions in entirety
> if you were willing to record every event as a record with a timestamp
> describing when that action took place. The storage of such events
> (T,X,Y,Z) is barred from storing any compositional knowledge about
> them or any of there terms. That is, if I store an inventory
> reduction, I am not allowed to store the total inventory, only the
> acts of reducing inventory in one spot and adding to another. In
> that case all I have to guarantee is that all of the events are
> captured in entirety, but that is fairly straightfoward to do, and do
> concurrently.

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

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.

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

Regards
Paul Vernon
Business Intelligence, IBM Global Services Received on Wed May 07 2003 - 18:53:37 CEST