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

From: Hugo Kornelis (hugo_at_pe_NO_rFact.in_SPAM_fo)
Date: 05/24/04 

Date: Mon, 24 May 2004 00:15:11 +0200

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)

Relevant Pages

  • Re: OT - Iraq photos too shocking for the main stream media to show!
    ... 20 of them say, in some manner, "John is sitting in a black chair" ... a report on the thought processes I used and experience I've ... intel might be faulty). ... am responding to. ...
    (rec.music.makers.percussion)
  • Re: Value from unbound form control
    ... I understand what you're saying about the extra field for a preferred phone ... since each vendor may have several. ... the person generating the report. ... button's Click event that opens the report). ...
    (microsoft.public.access.reports)
  • Re: Value from unbound form control
    ... I understand what you're saying about the extra field for a preferred phone ... since each vendor may have several. ... the person generating the report. ... button's Click event that opens the report). ...
    (microsoft.public.access.reports)
  • Re: Value from unbound form control
    ... PhoneNumber since each vendor may have several. ... DoCmd.OpenReport "rptVendorInfo", acPreview,, strLinkCriteria ... of the person generating the report. ... intended (in the command button's Click event that opens the report). ...
    (microsoft.public.access.reports)
  • Re: SF Sidewalk Observing (kinda long).
    ... daughter and I had dropped John off at his apartment ... Saturn, I had tears in my eyes. ... John will be at Scope City this Sunday, so if you plan to go you might see ... > Doing sidewalk astronomy is a transformational experience. ...
    (sci.astro.amateur)