Re: Help with complex db design concepts

mikharakiri_at_yahoo.com (Mikito Harakiri) wrote in message
> where a.contains(x) and b.contains(x)
>
> is logically the same as
>
> where intersects(a,b).contains(x)
>
> but I doubt if there are optimisers today that know about this
> identity.

   Absolutely right. But its worse than that:

    A.Overlaps ( B ) AND B.Overlaps( C ) does not imply that A.Overlaps ( C )   

   But some optimizers make transitivity assumptions, which is valid in the   case of all SQL-92 operators except LIKE. With ADTs, lots of things go wrong.   Postgres stores commutors and negators, but that isn't enough. Queries like   this are worse than being slow: they return wrong answers! Building an ORDBMS   means turning off a lot of optimizations, as well a creating opportunities for   new ones.

   A couple of observations:

1. Who cares? Todays's # 2 DBMS company (Oracle) out-grew its rivals (Ingres, Sharebase, etc) all of whom had much better optimization technology. Just being able to pose the question at all was incredibly valuable.
2. What's required is an optimizer model that stores considerably more information about the ADTs behavior than what today's commercial systems use. But theorem provers (which is what you're looking at here) are a fairly well understood programming problem.

   What you're saying is right, but it's not clear that it's a major    practical problem, or that if it becomes one it can't be solved. Just being    able to pose the queries at all is a big step forward. And my original    point ('spatial is red herring') had to do with the design question, not    an optimization question. I can't think of another solution to the    original problem that wouldn't be succeptable to exactly the same    problem.

      KR

               Pb Received on Mon May 27 2002 - 17:45:43 CDT