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

On 27 May 2004 21:38:41 -0700, Neo wrote:

>> >Show me a method to determine person's class with the provided
>> >solution and I will show you how it will fail if the data is changed
>> >(ie the name of thing is changed from 'thing' to 'thingy' or
>> >'object'). This failure will not occur with XDb1.
>>
>> [For Sol1] SELECT things.thing, classes.class
>> FROM things LEFT JOIN classes ON classes.thing = things.thing
>> WHERE things.thing = 'john'
>>
>> [For Sol2] SELECT things.thingName, classes.className
>> FROM things LEFT JOIN ClassOfThings ON ClassOfThings.thing = things.thing
>> INNER JOIN classes ON classes.class = ClassOfThings.class
>> WHERE things.thingName = 'john'
>
>The above are general methods for determining a thing's class(es)
>(which is what I meant, not just for john). If I substitute 'person'
>for 'john' both return 0 records.

In the challenge, there is no need to extract the class of 'person' from the database. The challenge had some classes (church, force, person, dog and computer, if I remember well). None of these had a superclass, other that the universal superclass "thing". Since everything is a thing, I did not store it.

If the challenge had called for the name "thing" to be flexible, I would have had to store it in a table. Because it's not functionally dependant on any other attribute, this would have been a seperate table, consisting of one column, and with some constraints to limit it to exactly one row. Than, the current name of "thing" can be taken from that table.

If you expand the challenge to include subclasses, things start to look different. In a previous post (one or two days ago, if I remember well) I outlined how my model would have looked like if your challenge had included the requirement that classes may have subclasses (and sub-subclasses, etc). Following the sound business rule of not writing code for customers that don't pay their bills, I won't go into details. But I can disclose that the hierarchies table would probably have looked somewhat like this:

  thing | relates | otherthing
  -------+---------+-----------

  person | isa     | thing
  john   | isa     | person
  john   | leader  | army
      (etc)

> The methods do not work because the
>isa relationship between person and thing in not encoded in the db as
>it was for john and person, mary and person, fido and dog, etc.
>Without being able to systematically determine that person isa thing,
>the db client cannot derive that john isa thing also.

With the requirements outlined in the challenge, the db client needs not derive that john is a thing or that person is a thing. Everything is a thing.

Best, Hugo

-- 

(Remove _NO_ and _SPAM_ to get my e-mail address)