Re: Demo: Modelling Cost of Travel Paths Between Towns

> > [Query "SELECT %.age & %.name=john;" works regardless of schema changes]
> > You are right, I don't see any advantages either.
>
> Then what is your point bringing up Xdb2 in this group?

To make sure that there is no advantage in representing things in a manner such that related code/query are resilient to unanticipated changes in schema.

> It really is about selling isn't it.

Yes, its really about selling, see www.xdb2.com/selling.asp for details.

> > ... What does "logically less complex" mean?
>
> Logically both queries perform the same operation.
> If you don't understand that comment, then there isn't much you are
> going to get out of this discussion.

You are correct, I didn't understand the comment. But now I understand what "logically less complex" means since "Logically both queries perform the same operation".  

> > Does your solution handle the following cases
> > without NULLs or redundancies:
> > 1. Things with no name and multiple names.
> > 2. Things with no age and multiple ages.
> > 3. Things with no name or age.
> > 4. Things with same name(s) and age(s).
> > 5. Things with variable number of classifications (ie martian and
> > plutonian).
 

> Why should I not use NULLs? No reason that I can see.

I can't see any reason either since you don't see one. I guess it is wrong to mix C.J. Date's theories with actual practice.

> Look, why don't you try this: Load Xdb2 with some real data (say a
> gigabyte or so would be a nice start), and build a real application on
> top for a real customer.

Sorry but XDb2 is only for non-real data. For proof, see thread titled "Database planning - Hierarchical problem" in comp.database.theory

> While there are changes in production systems, they do not go to the
> extend you seem to propose.

The extent to which changes go to in production systems can vary and tend to extend more in AI-type apps. For example, your system designer (nature/god) didn't know in advance your current language or profession.

> IOW, what kind of application systems is Xdb2 supposed to solve.

Possibly very small and insignificant AI-type apps. Possibly none.

> [XDb2] doesn't seem to be data management.

You are correct XDb2 doesn't manage data. It only creates, selects, updates and deletes things currently. (www.xdb2.com/nli/default.asp)

> And if as you said above, there isn't any advantage
> of Xdb2, why should I even consider using it over an RDBMS.

You shouldn't. You should use RDBMS. Please use it in thread titled "Database planning - Hierarchical problem" in comp.database.theory

> Let's see in summary: Xdb2 has NO basis in theory

You are correct. None what so ever.

> Xdb2 has a new unproven syntax,

Your are correct, it has a new unproven syntax (www.xdb2.com/NLI/default.com).

> Xdb2 has minor possible advantage in space saving.

I haven't specifically asserted this.

> I still think RDBMS is the better choice.

I think you are right. In the mean time, below shows how XDb2 handles some of the above cases without requiring changes to original query.

// Martian with no name or age

CREATE *martian.cls = thing; // Create a martian class
CREATE *;                    // Create a thing
CREATE it.cls = martian;     // Classify it as a martian

// Martian with multiple names
CREATE *;                    // Create a thing
CREATE it.cls = martian;     // Classify it as a martian

// Thing with multiple classes and multiple ages CREATE *plutonian.cls = thing;
CREATE *;

CREATE it.cls = martian;
CREATE it.cls = plutonian;
CREATE it.name = +john;
CREATE it.age = +10;
CREATE it.age = +"-3.14";

// Two Venutians with same name and age
CREATE *venutian.cls = thing;

CREATE *;

CREATE it.cls = venutian;
CREATE it.name = +john;
CREATE it.age = +very old;

CREATE *;

CREATE it.cls = venutian;
CREATE it.name = +john;
CREATE it.age = +very old;

// Execute original query
// (still works regardless of things represented) SELECT %.age & %.name=john; Received on Tue Nov 30 2004 - 21:20:21 CET