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

> > The report is as before except occurrences of 'fido' are
> > replaced with 'john'. In this case, printing each thing's class (ie
> > 'person/john', 'dog/john') would allow user to distinguish them.
>
> (giggle) not exactly, Neo. I got the following when I tried it...
> I especially like the line "john john john 1".

In general, there is roughly an app layer and a data layer. If the app has to change or extend its logic in order to meet new conditions (like adding a thing's class to the report, that in general is acceptable to me. But what is not as acceptable is either a failure to model the data correctly (ie the class hierarchy) and/or a schema that is non-generic (ie. two things can't have same name or inability to handle unamed things). The db implemented with XDb1 allows each thing to have 0 to many names, and any two things can have the same name, and the class hierarchy is explicit and can be of any depth.

After changing fido's name to john or creating a dog named john (the same name as that of the 1st person), the report runs "correctly" in the sense that it is the same as before except the word 'john' now also appears where 'fido' was before. Thus the prior output 'john fido john 1' became 'john john john 1'. Of course, now the problem is that the user can't distinguish john the person from john the dog, until the app adds that info. Previously, when I stated that XDb1 would print 'person/john' and 'dog/john', I meant XDb1 would be able to do it by altering the app layer but without adding additional data or modifying db schema, which is not the case with the provided solution, since it does not model the class hierarchy correctly (it fails to implicity store the class of 1st-level things such as person, dog, computer and it fails to allow deeper class hierarchies. See other thread for details).

> Please indicate which part of that message explains the requirement
> that duplicate names should not be allowed on entry...

The part that says "Report from normalized and NULL-less data and the solution must be as generic". For starters, a solution that can't handle multiple things with the same name is not as generic. But I know you could make your solution more generic to allow a fairer comparision. Received on Sun May 23 2004 - 01:28:42 CEST