Re: Nearest Common Ancestor Report (XDb1's $1000 Challenge)

> > Actually the provided solution is inconsistent in that the class
> > hierarchy of things ... isn't encoded in the hierarchies table.
> > It is instead encoded in a dedicated table named types.
>
> Yes, indeed. That's because I normalized the data (as requested in the
> original message). Note: see my other message as well, where I provide an
> additional table to keep track of the class hierarchy.

Even structure is data. The structure to store all hierarchies needs to be normalized. In the provided solution, the leader hierarchy is stored in the hierarchies table, as expected. But the class hierarchy is stored in types tables (which makes that hierarchy inaccessible to the procedure that generates the report). The fact that hierarchies are stored in two different tables is redundant/unnormalized. For example, in XDb1, if user right clicks the tree root node labeled 'thing' (which is the root of the class hierarchy), the nearest common ancestor class report is generated.

> > The procedure that generates the report utilize hierarchies table
> > and not the types table.
>
> Of course. If you'd replace the statement 'john isa person' by 'john isa
> dog' but leave all 'xxx leader yy' statements intact, the Common Ancestor
> Report would remain unchanged.

I think, you may be assumming I still want the nearest common ancestor leader among things. I want the nearest common ancestor class among things. How can I do that with the provided solution without the db having redundant data? Received on Wed May 26 2004 - 23:09:45 CEST