Re: A better SQL implementation?

J M Davitt wrote:
> 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.
Yes. Nice synthetizing. I think the set indices and the way operations are performed to limit IO reads part is the most convincing.

> 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.
Ful text is a mess using B-Trees or any traditional index technology. It's a performance(response time) killer. Don't you think?

> A different dialect of SQL? Well, he's added one more to the mix.
Yes but this one has the advantage of having interesting scaling up because db size independent.(read about IO accesses)

> 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.
Yes several people think so too.

> Efficacy and efficiency must be considered separately if they're
> each to be optimized.
Yes that's a more cautious approach but time lengthy approach. This guy does not have the luxury. That's why I wanted to give credit to his efforts. What he implemented may give us clues...That's the spirit of this thread/ Received on Thu Jun 08 2006 - 23:29:33 CEST