Re: A better SQL implementation?

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

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

The paper is rather confusing to me. It claims the index structure is the novel feature of Atlas but the author doesn't explain what the index structure is or how it differs from other indexes. The only clue is the diagram of "Normal" vs "Set" indexes but those terms and the diagrams are strange to me and they explain nothing. How does this system compare to bitmap indexes? Hashing? B-trees? Clustering? etc.

Throughout there seems to be the mistaken idea that SQL is a set-based data model and language. Informally, we often say that (I do anyway) but that's not really good enough for a serious discussion about database design and implementation.

Then there is this:

Select * from Document where parag = 'kw1' and parag = 'kw2'

If the author wants that statement to return anything other than zero rows then he has to define a whole new SQL syntax and apparently a different *logical* data model as well. He obviously isn't using SQL's model. But none of that is explained other than with trivial examples. Where is the grammar that describes the language he has used? Where is the formal specification of the data model?

Finally, since Atlas is neither SQL nor Relational why bother making it look like SQL at all? If the author thinks we need a new data model or a better language then better design one without all the baggage and the mistakes that have hindered SQL from the start. He patently isn't doing that. For example, SELECT * implies that logical column order is still a "feature" of his SQL. He even allows tables without keys. I can't understand why anyone who was serious about reforming SQL would keep such huge flaws in the language.

-- 
David Portas