Re: A better SQL implementation?

From: J M Davitt <jdavitt_at_aeneas.net>
Date: Fri, 09 Jun 2006 19:16:39 GMT
Message-ID: <rOjig.57403$P2.23222@tornado.ohiordc.rr.com>

Cimode wrote:
> 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?

I'm not quite sure what you mean. B-Tree, as I see it, is a general purpose indexing scheme; I'm sure there are others which are better suited to certain problems. And I'm not sure that set indices are very different from some hashes or "any other traditional index" scheme.

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

And this is where I think we have the greatest gap: I don't think that the language should have anything to do with scalability.

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

I think separating the two is necessary, not merely cautious. When the correct language and the correct implementation are brought together, the result is serendipitous. But the language must be defined before the implementation can be specified. And, as other have pointed out, the version of SQL presented here is probably not a good solution to very many data management problems.

It's a significant bit of work in a couple areas and provided some insight into some problems, but it's neither a replacement for SQL nor an implementation that will solve many problems. Received on Fri Jun 09 2006 - 14:16:39 CDT