Re: Transactions: good or bad?

> Meaning?

A database server based upon a virtual machine architecture with atomic instruction execution can be as concurrent as a traditional relational database server design. The system is not only potentially faster, but, also offers better theoretical performance in the case of concurrency control because it avoids many of the "time shifting" problems that Paul speaks about.  

> Well, you can't say something is Mathematics because it has to
> do with a the plus, minus and division signs... so you have to find a
> better basis to call your language, whatever it is, relational.

Not really.

First off, the relational theory behind a database server is a small subset of what it takes to make a relational database server actually work that I doubt you can credibly say that any relational database is mathematically based. Secondly, I think the mathematics is a language for expressing formal ideas, but, it is only one of many languages, and that, an idea expressed in software is every bit as formal as any mathematical proof, if, test cases exist for all the cases of that software.

For most customers, the concept "relational" implies that the result of an expression can be operated on as if it were one of the components of that expression. That is, WHERE works on a SELECT of a table as well as it does on a SELECT of a SELECT. For the domain that my language exists, I have this characteristic.

I think relational database servers are a dead end, and domain specific languages are the way to go. It was an elegant theory, but business needs have moved beyond simple the aggregation and combination of regular structures. Since most DBAs tend to suck anyway, I think I will be the winner of the choice most businesses can make. They can either buy my database server off of the shelf, or they can take a crap shoot with some so-called super DBA to try and hammer a general purpose tool into something useful.

This does not mean that DBAs are obsolete. They are not. But what it does mean is that instead of getting really good at mastering the ins and outs of a super general purpose tool, they will have to learn many more specific purpose tools. This will open up, incidently, project management opportunities for DBAs in a much greater way than being a guru of a SQL script could ever be.

In short, domain specific languages are better for businesses, better for DBAs, and certainly better for me. If you or anyone else would like to explore what I have to offer, please give me a shout at tbandrow_at_unitedsoftworks.com.

Thanks! Received on Sun Jun 08 2003 - 19:42:19 CEST