Re: A better SQL implementation?

From: David Portas <>
Date: 8 Jun 2006 05:51:14 -0700
Message-ID: <>

Cimode wrote:
> Concerning the following query using the Document data type:
> Select * from Document where parag = 'kw1' and parag = 'kw2'
> Looking at the paper, you can see that the author declares the
> following according to the query:
> "It should be noted that the above select would give zero results for
> any SQL database other than Atlas, since a single column cannot contain
> more than one value. "

So this is a multi-valued DBMS not a relational one. The multi-valued features are not fully explained.

There are three reasons given for creating a new syntax. The first and seemingly the main justification is the alleged poor performance of the original syntax. That's nonsensiccal. Performance is defined by the implementation not by a language. One might as well observe that a red Ferrari goes faster than a blue truck and then conclude that red makes vehicles go faster!

The second reason given is that the old syntax may be hard to write or understand. Yet, the new syntax assigns a new and contradictory meaning to the most basic and well understood mathematical operator of all: the equals sign. Is that really going to be easier to understand? To me it looks like the consequences will be far worse than SQL's three-valued logic (Of course I'm guessing because the syntax is never explained. How does the new = operator affect the meaning of OR, NOT, NULLs for example?). You mentioned the CONTAINS syntax, which seems far more user-friendly than what is proposed in the paper.

Thirdly the author says he doesn't think he can extend and generalize the original SQL query he gave. In fact he could have used COUNT(DISTINCT) to do exactly that but the query given is not the easiest way to solve the problem in SQL. It could have been written much more easily as N self-joins.

David Portas
Received on Thu Jun 08 2006 - 14:51:14 CEST

Original text of this message