Re: A better SQL implementation?

I want to thank all people for participating at this thread. Ihave to say bye because I am leaving to Vienna (week end trip). Be back on monday...See you all soon..

Cimode a écrit :

> 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:35:51 CEST