Re: Transactions: good or bad?
Date: Sun, 08 Jun 2003 22:10:28 +0200
Message-ID: <pan.2003.06.08.20.10.25.975643_at_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=leandroReceived on Sun Jun 08 2003 - 22:10:28 CEST