Re: parent/child relationship in the same table.

> Well, but if those folks spend most of their time arguing
> whether it is safe to inherit circle from ellipse,
> you wouldn't expect innovative query optimization
> technique coming from that camp, right?

You are right, I probably would not expect it.

> >The solution was presented using standard SQL and programming
> >techniques, which I believe will require nested loops? Can you provide
> >an alternate practical solution using standard SQL and programming
> >techniques?
>
>You call SQL from a function that you invoke recursively.
>That's just one and not very efficient possibility:
>essentially, you coded some execution plan for recursive SQL.
>Note, that if some incremental evaluation system is in place
>(for example, materialized paths, Joe Celko nested sets, etc)
>the optimiser can choose a different plan.

Can you show us an alternate solution?

> What is "resolution time" may I ask?
A fancy term for nothing, a benchmark would be better.

> OODB is losely defined entity to draw any conclusion what database is faster
> today. Given that RDB has some flexibility in choosing the access path to the
> data, many people believe that RDBMS are faster. Even on unconventional topics
> like calculating transitive closure.

You may be right.
Would you like to verify the above in a specific case with a benchmark?

> >Would you like to benchmark "pipelining" with XDb which resolves
> >parent/child relationships at a rate of 100 mil/sec on a 800Mhz PC?
>
> So what? If one can cook some one-user in-memory "database", no doubt, there
> would be a benchmark where it rocks.

True, it would be an apple-to-orange comparison, we would need to compensate when comparing results and drawing conclusions. Received on Tue Nov 20 2001 - 00:20:53 CET