Re: A better SQL implementation?

From: J M Davitt <jdavitt_at_aeneas.net>
Date: Thu, 08 Jun 2006 17:18:21 GMT
Message-ID: <xZYhg.56677$P2.1781_at_tornado.ohiordc.rr.com>


Cimode wrote:
> Below is a link to a friend's website who developped his own
> implementation of SQL considering that all current SQL implementations
> are unefficient. This SQL is embedded into his database engine (Atlas)
> Atlas defined a DBMS *set system* as a reference to set theory.
>
> As an indicative annotation, he was a part of the developping team that
> worked on System-R.
>
> He has an interesting truth based historical perspective about
> evolution of SQL implementations from early days and supports that SQL
> should have been implemented otherwise. Here's a link to a white paper
> put on his website. I would like your opinion on that.
>
> http://www.armadillo.fr/english/whitepapers/WHITEPAPER_2004.htm
>

To me, it seems that there are two different ideas described here. One is an alternate implementation that makes use of "set indices," the other is an alternate dialect of SQL.

Undoubtedly, there's more than one way to store data in a database; the direct image and column store approaches are popular. Indices? Some products provide many approaches to indexing; B-Tree isn't the only game in town. In fact, B-Tree should be thought of a widely useful, general purpose scheme that usually doesn't hurt too much but often isn't the best.

A different dialect of SQL? Well, he's added one more to the mix.

For certain problems, his solution is probably a good one. But I can't help thinking that a completely different language would be a better approach and that implementation should not be part of the language.

Efficacy and efficiency must be considered separately if they're each to be optimized. Received on Thu Jun 08 2006 - 19:18:21 CEST

Original text of this message