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

> > ...the provided solution doesn't properly model ...the class hierarchy.
>
> Oh, so THAT is what you want! Why didn't you say so directly from the
> start? Because, you see, your original post failed to point this out.

Yes, the term ancestor was amibigious in the sense it was meant to apply to any of hierarchy (class/instance, parent/child, asm/part, leader/follower, etc)

> But since I'm in a good mood, I'll provide you with the necessary change
> free of charge (note that I changed the name of the types table to
> classes, if you didn't change "references classes" to "references types")
>
> CREATE TABLE ClassHierarchy (SubClass varchar(20) not null ...
> SuperClass varchar(20) not null ...
> primary key(SubClass, SuperClass))

I consider a solution that stores the class hierarchy in T_ClassHierarchy (formerly T_Types) and the remaining hierarchies in T_Hierarchies to be structurally redundant/unnormalized (Yes, even structure is data in my book). Why is one hierarchy being stored in a different table than the remaining? Received on Wed May 26 2004 - 23:31:46 CEST