Re: A better SQL implementation?
Date: 11 Jun 2006 13:29:05 -0700
J M Davitt wrote:
> 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.
> >>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"
I meant that in traditional SQL-DBMS Full text are ont natively stored in the database and are are physicall stored as sets of 8 to 32 kb that have their own indexing schema. From my experience with these features they are a mess: reponse time time get severaly increased wheb databases increase, time for backup are a mess, rebuilding if Full text catalogs are often comple and not incremental...
> >>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.
Not the language suntaxically but the underlying physical operations that take place...The IO accesses are limited in profit of CPU work..As opposed to traditional SQL, the indexing technology allows to use a more domain oriented handling of operations such as intersection...Check the logical accesses examples posted they are pretty convincing...The caching approach is interresting in the sense that cached execution plans allows various combinations of AD/OR conditions using simlar showplans...
> >>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.
Yes I agree but this guy went through these steps on the past 30 years...What's implemented is a result of a lentghy process of reflexion and experience...No doubt the result is far from being perfect and can certainly be improved but it gives some interesting tracks...
And, as other have pointed out,
> the version of SQL presented here is probably not a good solution to
> very many data management problems.
I would not argue that because I have not tested ALL feature of the DBMS ATLAS. I speak only from the observations I have madet...Been putting 100 Gb of different document types.Tested several FULL TEXT type select statement using some combinations of conditions (AND/OR, AND OR, = VS <>) the results are uncomparable in terms of response time....I still need to test COUNT, SUM and handling of missing data though as well as transaction concurrency and security...
> 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.
I do believe it points out areas left away at implementation level on current SQL DBMS
It 's is not replacement for SQL as the puposed of this thread was to give some ideas...And I do believe this approached maybe not the syntaxic part may help some real problems DBA's are facing everyday... Received on Sun Jun 11 2006 - 22:29:05 CEST