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

On 20 May 2004 12:04:33 -0700, Neo wrote:

>> > Among other things, the difference in normalization between the
>> > implementations is quite different.
>>
>> It should not matter HOW my implementation generates the report.
>
>It does matter because a less generic and unnormalized implementation
>will cause more problems or even fail under a broader scope. For
>instance when the names of two things are the same.

I have to agree that like-named things cause a difference. My RDBMS implementation will refuse such input instead of making a hideous mess of things like XDb1 does. But let's not repeat the same things over and over again - check my previous message for the details.

>Another isssue with the provided implementation is that the class
>hierarchy is not modelled faithfully. A part of the original hierarchy
>is shown below:
>
>thing
> god
> person
> john
> mary
> dog
> fido ...
>
>In the provided implementation, the class hierarchy is (flat):
>
>thing
> god
> person
> john
> mary
> dog
> fido ...

You obviously didn't check my model too well. If you really want to use a tree-like notation to show how my model stores thing (which can only be achieved by stretching things very far, since I didn't use a tree-like model to begin with), you should arrive at this:

[thing]		-- Not stored. Since everything is a thing be definition,
		-- there's no need to explicitly store that information.
		-- Some would even call it redundant.
  god		-- Leaf level, therefore it's a thing.
  person	-- Not leaf level, therefore it's a class.
    john	-- Leaf level, therefore it's a thing.
    mary	-- Leaf level, therefore it's a thing.
  dog		-- Not leaf level, therefore it's a class.
    fido	-- Leaf level, therefore it's a thing.

As you can see, apart from removing the redundant storing that everything is a thing, there is no difference.

Not that it matters anyway. Models are not a goal, but a tool. They are used to model things from the real world. The only valid comparison between two models is in comparing what they can or can't store.

Your example of two things with the same name is a very valid way to test these models against each other. Unfortunately (for you), the XDb1 model failed that test in a much more spectacular way than my model.

>Thus, if a person is named 'skippy' and a dog is also named 'skippy',
>and we print a thing's class to distinguish them on the report, XDb1
>would print:
> person/skippy
> dog/skippy

No, it wouldn't. I tested it (with the name 'john' instead of 'skippy', but I don't suppose that will matter) and XDb1 messed up big time. See my other message for details.

>whereas the provided implementation would print:
> thing/skippy
> thing/skippy

No it wouldn't. It returns an error:

Server: Msg 2627, Level 14, State 1, Line 1 Violation of PRIMARY KEY constraint 'PK__things__64CDBE05'. Cannot insert duplicate key in object 'things'.
The statement has been terminated.
Server: Msg 2627, Level 14, State 1, Line 1 Violation of PRIMARY KEY constraint 'PK__types__66B60677'. Cannot insert duplicate key in object 'types'.
The statement has been terminated.

You see, unlike you I *do* test my code before I make claims here.

Best, Hugo

-- 

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