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

On 22 May 2004 13:50:44 -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 matters because a non-generic/unnormalized implementation
>is more likely to experience problems over a broader scope. Here is
>another example, consider what happens when a thing has no name. Since
>the provided solution specifically uses a thing's name to represent it
>and link between tables, the provided solution will fail to represent
>a non-named thing (ie a person whose name is unknown or doesn't have
>one).

Hi Neo,

Yes, that's correct. If the challenge had included the requirement to store unnamed things as well, I wouldn't have designed my tables the way they are now. Note however that things without name tend to be a PITA when you want to do anything useful with it, unless other attributes are stored that can be used to identify exactly which thing one wants to discuss.

>On the other hand, the XDb1 db's schema (created by the simple
>english-like script) allows a thing to have 0 to many names. In XDb1's
>db, the name is an attribute of a thing, the name isn't the thing
>itself.

The same holds for a relational database. In my design, the name is also an attribute (aka column). Since I declared it as primary key, it has to disallow nulls. If the challenge had called for nameless things, I would have used a different primary key (probably an autogenerated integer that would never be exposed to the end users).

> The easiest way to check this functionality is to unname john
>in a completed db. To unname john, click thing/person/john twice with
>a small delay to enable edit mode. Clear out 'john' and press enter.
>Note, when a thing has no name, XDb1 displays it's secondary classes,
>if any and its properties, if any, thus after unnaming john, one will
>see 35, his age. In addition, the report will run as before, except
>'john' will be replaced with 'person 35', the unnamed things classes
>and properties.

I checked, and this does indeed work as advertised.

>If you insist that unnaming a thing is not the same as creating an
>unnamed thing in the first place, you can create the db with the
>original script, except replace all instances of the word 'john' with
>'*'. XDb1's NLI takes '* isa person' to mean, create an unnamed
>instance of person class. In succeeding statements, '*' continues to
>refer to the last unnamed thing created (XDb1's NLI is currently far
>from complete and its GUI or API is required for many operations).

This incompleteness shows if you try to enter an unnamed person, an unnamed dog and an unnamed computer. Changing all 'john', 'fido' and 'laptop1' to '*' in the script is a good way to mess things up big time. While multiple unnamed things are indeed allowed, it becomes impossible to explain to XDb1 which of the unnamed things I'm referring to. As far as I'm concerned, this shows why it's generally better to insist on naming things.

Of course, you already pointed out that the NLI is incomplete. I'm sure that you'll find a way to improve this. But please do note that I can change my SQL Server database to allow nameless things without having to contact the databse vendor, whereas an XDb1 user is stuck with the current functionality until you find the time to fix this.

Both implementations do not provide full support for things without name, things sharing a name or things having multiple names. All these points can be addressed in my implementation by adding and/or changing some tables and/or columns, with no need to contact the vendor. All these points can only be changed by the vendor in XDb1's implementation. I'd say that, unless you happen to *be* the vendor, my implementation should be considered more generic.

>The main point I wanted to emphasize is not what the GUI has or hasn't
>implemented, but the broader scope afforded by representing data with
>high degree of flexibility and normalization (replacing redundant
>things with a suitable ref to the original; things' names are not
>suitable refs).

**IF** the problems' requirements are such that one might expect the need to store unnamed things, then the name should not be considered as possible primary key. But since that requirement was not clear from your original $1000 challenge post, it doesn't invalidate my claim.

Best, Hugo

-- 

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