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

On 22 May 2004 16:28:42 -0700, Neo wrote:

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

Hi Neo,

I think that being the developer of a database gives you a slightly different view on things than other people have. For you, chainging the application might be easy. But what if I had bought XDb1 and actually *needed* this report - including the need to distinguish john the dog from john the person? The only way to accomplish this would be to contact you and ask if you could please make a patch to enable this for me. Well, maybe you and your partners are a brilliant and very service-minded group. Maybe you'd spend the whole night at your computers and send me the patch first thing in the morning. But then again - maybe not. Maybe you're having a day off. Maybe you have a policy against sending out patches. Maybe you are all busy for another customer first. There is no way that I (or my boss) can direct you to change the application *NOW*. And that's the kind of dependency that puts many decision makers off.

On the other hand, my implementation can be changed by almost any DBA or SQL coder. Add some tables of columns, convert the data, change the procedure, test it ... and it's already done. If we're in a hurry, my boss can tell ME to drop everything else and solve this first. He can order me some food and have me phone my wife that I'll be working late again. He can rely on me (or another DBA/SQL coder) to have the change done in a short time. That's the kind of flexibility that bosses tend to like.

>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 would require placing a service request by the database vendor

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

I already provided an extra table to address the possibility of class nesting (which incidentally was not clear from your original post).

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

1. Your quote is incomplete. In the original message, the requirement "must be as generic" was defined as:

(quote original message)

	"(...) must be as generic, meaning allow the user to create
	 any hierarchy, consisting of different types of things
	 (each type to allow different attributes) and each thing
	 in the hierarchy to have any number of parents."

My implemetation does allow the user to create any hierarchy (which XDb1 doesn't), it does allow different types (classes) of things in each hierarchy, it does allow each type and even each thing to have it's own attributes and each thing may have any number of parents. I met all the requirements you stated. You didn't state anything about things sharing the same name.

2. Now let's suppose that I had somehow guessed that the above quote was not intended as the definition of "generic" for this challenge. In that case, the phrase "must be as generic" seems to miss something: it must be as generic as what? I think this can only be taken to mean "as generic as described in this message and the related web page". There's nothing in the message or on the web page to indicate that multiple things might have the same name. In fact, both the sample data and the NLI used to describe the challenge seem to indicate that a thing's name is unique within the universe of discourse.

3. Let's take it one step further. Let's pretend that I had somehow guessed that you meant "as generic as XDb1". Then you would have set an impossible task, since there's nobody who knows exactly how generic XDb1 is except you - and you didn't tell us in the original message! You didn't seriously expect me to go disassemble, decompile and reverse engineer XDb1, now did you? But in fact, that would have been the only way to know how generic XDb1 is! Without either me disassembling the program or you telling me how generic it is, how can I know whhat XDb1 can or can't do? Heck, maybe you've even put foreign language support in it and you're going to dismiss my entry for not understanding "god istein ding." or "john estun person."

But of course you wouldn't want all takers of your challenge to go and reverse engineer XDb1. So I immediately knew that you didn't mean "as generic as XDb1", since if you had, you'd surely have provided full details on how generic XDb1 is. Which brings me back to point 1, the full quote, which I at that time took for a description of how generic XDb1 is.

> But I
>know you could make your solution more generic to allow a fairer
>comparision.

I could, but I won't. Not now. I don't want to compare, I entered a challenge and I want to collect the prize.

Best, Hugo

-- 

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