Re: Transactions: good or bad?

From: Leandro Guimarães Faria Corsetti Dutra <lgcdutra_at_terra.com.br>
Date: Sun, 08 Jun 2003 22:10:28 +0200
Message-ID: <pan.2003.06.08.20.10.25.975643@terra.com.br>

On Sun, 08 Jun 2003 10:42:19 -0700, Todd Bandrowsky wrote:

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

Pointers? This is not clear yet.

Anyway I think you are confusing transactions with data models. Don't.

And the state-of-the-art is not transactions, but database assignment. So don't loose your time beating a dead horse.

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

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

Your are messing relational with SQL. SQL is not relational, and has never been. Relational were QUEL, BS12, and now are Opus, Duro, Dataphor and perhaps LEAP.

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

You are messing testing with proving. Test cases aren't formal proofs. I hope I don't have to use software coded by you for reliability.

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

Most customers don't understand what relational is all about. Most customers can't define what's relational any more than they can define what Mathematics is.

> I think relational database servers are a dead end, and domain
> specific languages are the way to go. It was an elegant theory, but

So why the effort of misbranding your wares?

> business needs have moved beyond simple the aggregation and
> combination of regular structures. Since most DBAs tend to suck

You could be clearer, but since you are confusing relational with SQL it probably doesn't matter anyway.

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

Spammer.

-- 
 _
/ \  Leandro GuimarÃ£es Faria Corsetti Dutra     +41 (21) 648 11 34
\ /  http://br.geocities.com./lgcdutra/         +41 (78) 778 11 34
/ \  Responda Ã  lista, nÃ£o a mim diretamente!   +55 (11) 5686 2219
Rate this post if helpful: http://svcs.affero.net/rm.php?r=leandro

Received on Sun Jun 08 2003 - 15:10:28 CDT