Re: A better SQL implementation?

From: paul c <toledobythesea_at_oohay.ac>
Date: Thu, 08 Jun 2006 18:00:08 GMT
Message-ID: <IAZhg.18$6%2.4@pd7tw1no>

Bob Badour wrote:
> J M Davitt wrote:
>

>> Cimode wrote:
>>
>> A different dialect of SQL?  Well, he's added one more to the mix.
>>
>> 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.

>
> From what others have posted here, the 'solution' is not a solution at
> all but a very bad problem instead. How does one express equality? For
> instance, if one has two paragraphs from different documents, how does
> one determine if the paragraphs are the same?
>
> Equality is both symmetric and antisymmetric, which makes it
> commutative. Contains is neither symmetric nor commutative.
>
> What does join mean if one redefines equals to mean contains? How many
> optimizations might depend on the symmetry of equality? The whole idea
> undercuts the information principle. I find the proposal remarkably
> daft. It's even worse than Pick, and we all know how daft that is!

It seems daft to me too. Even if the author's assumptions about current products aren't up-to-date, surely he ought to be aware of Codd's 1970 paper which I seem to recall allowed 'theta-join'.

Also, I think we'd be in even bigger trouble if equality under the rm could mean any old thing at any given time (the way equality under the law seems to). Why wouldn't the author define the typed operator he wants, same as lots of products do, such as the suggested 'contains'?

p Received on Thu Jun 08 2006 - 13:00:08 CDT