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

From: Hugo Kornelis <hugo_at_pe_NO_rFact.in_SPAM_fo>
Date: Mon, 24 May 2004 00:51:05 +0200
Message-ID: <eu82b0dqps3bmvahc25jb2t9f6qnv5tv8g_at_4ax.com>


On 22 May 2004 15:40:42 -0700, Neo wrote:

>> Now please tell me why a user who wants to name a dog 'john' would first
>> enter its name as 'fido' and then change the name later?
>
>You are technically correct. Here are the steps to enter a dog whose
>name is 'john' right from the start of his instantiation.
>
(snip)
>
>Currently XDb1's NLI is quite incomplete. For many operations, user
>must use GUI or API.

Hi Neo,

Though this works, it is still far from intuitive. How would an avarage end user know that there already is a thing named 'john' in the database when (s)he is required to enter dog john's data? This would force the end user to always check if the name is already in use.

The '*' for unnamed notation also introduces other problems which I point out in another message.

> My goal isn't to demo NLI/GUI's limited strengths
>and many weakness, but that data can be represented in a highly
>normalized and generic manner and that it can be processed quickly
>especially when the equivalent data/schema is spread out over several
>tables in RM.

I think I better not comment this....

>Thus, while the db created in XDb1 allows things to have the same name
>(right from the start) and the provided db doesn't, it is not as
>generic of a solution.

Like I said in another message, neither XDb1's implementation nor my implementation for SQL Server provide full support for this. This support can be added to my implementation by everyone with basic table design skills and some SQL experience, without a need to contact the vendor; for the XDb1 implementation full support for things with the same name can only be provided by the vendor. This makes XDb1 the more flexible and generic implementation for Neo and my db the more flexible and generic implementation for everybody else.

> But I know you could make it more generic so a
>fairer comparision can be made.

I can indeed. In another message I posted earlier today, I already described a possible way to do this. If you have an urge to compare XDb1 to SQL Server, by all means use my suggestions to change the solution I came up with (which probably is *not* the fastest solution possible).

As far as I'm concerned, this discussion is not about comparing products, but about a $1000 challenge that you put up. I gave you an implementation that met all requirements that you have set in your original message. I am not telepathic, so I probably have missed one or two requirements that you didn't include in your message. Since telepathy was not a requirement either, I consider all your remarks about things with no names, things with multiple names, multiple things with one name and whatever you'll come up with next as interesting stuff for a discsussion, but irrelevant to the challenge.

You owe me $1000, Neo.

Best, Hugo

-- 

(Remove _NO_ and _SPAM_ to get my e-mail address)
Received on Mon May 24 2004 - 00:51:05 CEST

Original text of this message