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

On 22 May 2004 17:31:56 -0700, Neo wrote:

>> "(...) and the solution must be as generic, meaning allow the user to
>> create ANY hierarchy, (...)" Now, I just tested what would happen if
>> I tried to do the same kind of thing with the XDb1 solution.
>> I entered "laptop1 leader2 trinity." and got the following error
>> message: "Invalid relator."
>
>The error message is correct in the sense that XDb1 does not know any
>relator named "leader2". It needs to be "taught" new relators and one
>can't teach it simply by using it in a sentence. Thus far you have
>mostly seen 'X isa thing' or 'Y is red'. XDb1 knows these and a few
>others because the db was "taught" these during its creation. User can
>"teach" ANY relator, but currently it requires the API and some work
>is required to make it user-friendly. Which relator would you like me
>to add to the downloadable db at the website?

No, don't bother. If I want to add a new relator, I'll just enter it to the hierarchies table in my relational design. That's a lot easier than going back to the database vendor every time I need a new hierarchy :-)

> Thus the provided
>solution is more generic in relation to hierarchies. However,
>currently the provided solution doesn't properly model the most
>important hierarchy, the class hierarchy. In XDb1, classes can form a
>hierarchy. This is not possible in the provided solution as the
>hierarchies table is not used.

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.

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

                                                    references classes
                                                    on update cascade
                                                    on delete cascade,
                               SuperClass varchar(20) not null
                                                      references classes
                                                      on update cascade
                                                      on delete cascade,
                               primary key(SubClass, SuperClass))

This is assuming that a class can be a subclass of multiple classes; if not, change the primary key to cover only the SubClass column. I think you can work out the INSERT statements for yourself.

Also, since neither the class of a thing, nor it's classes' position in the class hierarchy is needed for generating the Common Ancestors Report, you can expect performance for generating it to remain unchanged.

Best, Hugo

-- 

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