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

From: Hugo Kornelis <hugo_at_pe_NO_rFact.in_SPAM_fo>
Date: Thu, 27 May 2004 22:50:55 +0200
Message-ID: <gckcb0puqi70hdkt1f01gv1nejui8dnku8_at_4ax.com>


On 26 May 2004 14:31:46 -0700, Neo wrote:

>> > ...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)

There is no parent/child hierarchy in the challenge, nor any asm/part hierarchy. There is a class/instance relationship, but the challenge did not contain anything that might lead to the conclusion that this relationship was hierarchic as well.

>> 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?

Because I tacked a quick fix onto an existing model to meet the extra requirements you were starting to throw in. Because the original requirements only mentioned things; things being instances of a class and things forming a hierarchic "leader/follower" relationship.

You are right that this is a kludge. I should redo my model right from the start. Replacing the things and the classes tables with one catch-all table. And using the existing hierarchies table to store both the "leader" relationships and the "isa" relationships as well. I wouldn't even have to change the part of the code that actually generates the report!

On the other hand - if I do a fixed-price job for a customer and he starts changing the requirements after the job is finished, I bill him for the extra hours. Will you pay me extra if I rework my implementation as described above? No need to pay my normal hourly rate - just say how much you'll pay. Good chance that I'll bite.

Of course, I do still expect the $1000 you owe me for fulfilling all requirements set forth in your original challenge message. I assume that you've already paid and that delays caused by international banking issues are the reason that I didn't receive anything yet?

Best, Hugo

-- 

(Remove _NO_ and _SPAM_ to get my e-mail address)
Received on Thu May 27 2004 - 22:50:55 CEST

Original text of this message