Re: A better SQL implementation?

David Portas wrote:
> Cimode wrote:
>
> > What prevents using '=' as an operator to
> > mean 'CONTAINS' concept.
>
> Common sense. Why give the same operator two different (and potentially
> contradictory) meanings? In this case you can't even determine the
> meaning from the rest of the context so it's doubly bad and doubly
> dangerous.
Not the operator the syntaxic representation of the operator...But that's a valid point I agree it may be confusing and dangerous. OTOH I find it synthetic and elegant.

> > If you believe SQL has a sufficient support of complex data types such
> > as Document (set of words), what are the operators would define this
> > particular data type then using traditional SQL? (thank you for
> > adressing this particular definition.)
> >
>
> SQL has LIKE:
>
> WHERE document LIKE '%foo%' AND document LIKE '%bar%'
This kind of operator is limited to 8K in SQL Server and 32K on ORACLE...What about performance?

> > But I also believe the argumentation developped by the paper
> > exclusively concerns physical implementation even if he is not using
> > the right terminology. Index are implementation level and problems
> > expressed are real. I have encountered them countless times with
> > traditional SQL.
> >
>
> The argument *should* be one of physical implementation. But the paper
> says nothing useful about it! It presents no new implementation
> features at all. Most of the paper is taken up with discussion of
> queries, which have nothing to do with implementation.
I do not quite agree. The paper not only adresses queries but also IO accesses in terms of how many reads are made. It clearly is physical don't you think?

> > I am curious as to why you believe that the logical meaning of '=' is
> > redefined by the author. He just uses the operator to define a
> > specific data type...
>
> If the author was using the usual logical meaning for = then the
> expression:
>
> kw = 'kw1' and kw = 'kw2'
>
> could not evaluate to anything other than FALSE (or UNKNOWN in 3VL).
> That's not the result implied by the paper. Maybe he means we are to
> interpret his queries differently somehow. Since he explains nothing we
> have to guess everything.
True but keep in mind this is not for technical audiences.

> > Let's give him a chance...
> >
>
> I don't think he's said anything that has a chance really.
>
> --
> David Portas
The implementation is convincing though. At least at first sight...It may bring some interesting ideas for future implementations. Received on Thu Jun 08 2006 - 23:20:59 CEST