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

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

XDb1 can accept two things whose attributes do not allow them to be distinguished (ie two persons named john). Why? Because such situations can come up in the real world.

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

Yes, XDb1's NLI is limited and thus user would need to use the GUI or API in the case of multiple unnamed things.

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

I agree it is better to name things from a db/programmer's point of view, but sometimes reality doesn't provide one. For example, individual desks, chairs, pens, etc usually don't have names? It is possible to tell XDb1 exactly which unamed thing via GUI and API, but not NLI.  

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

User can use XDb1's current GUI or API to handle multiple unnamed things.

> Both implementations do not provide full support for things without name,
> things sharing a name or things having multiple names.

True but XDb1's data/schema does allow each thing to have 0 to many names while the provided solution's data/schema does not. Received on Wed May 26 2004 - 19:25:42 CEST