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

> > Another isssue with the provided implementation is that
> > the class hierarchy is not modelled faithfully.
>
> You obviously didn't check my model too well.

My apologies. Because I was trying to limit the complexity of understanding the provided solution, I had removed tables (T_Types and T_Attribs) from the script that were not being accessed to generate the report. And when looking thru the abridged script, I could only conclude (wrongly) that the class hierarchy was simply encoded in the table named things since I didn't find it in the expected hierarchies table.

However, after looking thru the original script, I find the following lack of genericness and normalization.

1. A minor (but crucial) point. The data in types table does not encode the class of force, church, person, dog and computer which should be thing. Probably the reason it didn't is because there is (correctly) no record for thing in things table and RM doesn't provide a way to reference a table, only records in a table (XDb1 is different in this respect, it can in effect, reference a record or a table equally). While some might say, it is implicit that person isa thing, I would say this is failure to properly model the relationship between data. In the provided solution, the method used to get the class of john does not work to get the class of person. In XDb1, T_Ref_Xth(pAnyThing, rCls) provides a systematic method to determine the classes of any thing.
2. Because the procedure which creates the report utilizes hierarchies table (and not the types table), it is impossible to create a nearest common ancestor report for the class hierarchy (without adding redundant data). In XDb1, because all hierarchies are encoded similarly, the procedure which creates the report handles the class hierarchy the same as any other.
3. But more importantly and fundamentally, encoding the class hierarchy in tables other than the hierarchies table is redundant/unnormalized.