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

From: Neo <neo55592_at_hotmail.com>
Date: 21 May 2004 21:55:39 -0700
Message-ID: <4b45d3ad.0405212055.20aa9bd0_at_posting.google.com>


> You obviously didn't check my model too well. If you really want to use a
> tree-like notation to show how my model stores thing (which can only be
> achieved by stretching things very far, since I didn't use a tree-like
> model to begin with)...

You stored the following data in a table named things:   god
  army
  trinity
  john
  mary
  luke
  fido
  laptop1

The relationship between a table and its records is that of class and it's instances. The provided table above is equivalent to:

  god isa thing.
  army isa thing.
  trinity isa thing.

  john isa thing.
  mary isa thing.
  luke isa thing.
  fido isa thing.

  laptop1 isa thing.

which doesn't match the original structure. Thus the provided solution, has no way to determine that john is a person and that fido is a dog. Only that they are both things, which does not allow one to print differentiating class info on the report if both were named the same. Its not a big problem, I know you could fix it.

>[thing]  -- Not stored. Since everything is a thing be definition,

> -- there's no need to explicitly store that information.
> -- Some would even call it redundant.

But you did store it. It is stored as the name of the table. Being explict is not equivalent to being redundant.

> [thing]
> god -- Leaf level, therefore it's a thing.
> person -- Not leaf level, therefore it's a class.
> john -- Leaf level, therefore it's a thing.
> mary -- Leaf level, therefore it's a thing.
> dog -- Not leaf level, therefore it's a class.
> fido -- Leaf level, therefore it's a thing.
>
> As you can see, apart from removing the redundant storing that everything
> is a thing, there is no difference.

There is a difference. In the diagram above, the indentation of john and mary under person indicates john and mary are persons, and the indentation of person under thing indicates person isa thing. These relationship can't be derived from your db schema. In XDb1's db, 'john isa thing' is not stored because it can be derived. Since 'isa' is transitive 'john isa thing' is derived form 'john isa person' and 'person isa thing'. While it is true that everything isa thing, it is also true that only some things are persons and only some things are dogs. The provided db schema doesn't allow determination of the later.

> >Thus, if a person is named 'skippy' and a dog is also named 'skippy',
> >and we print a thing's class to distinguish them on the report, XDb1
> >would print:
> > person/skippy
> > dog/skippy
>
> No, it wouldn't.

By 'would', I did not mean to imply that it currently does, but that it could. The point being that XDb1's db has the proper schema/data to allow an application to print the distinguishing class info. In the provided schema/data, currently that is not possible.

> >whereas the provided implementation would print:
> > thing/skippy
> > thing/skippy
>
> No it wouldn't. It returns an error:

Yes, I realize the provided solution doesn't allow two things with the same name. I was just anticipating the next problem due to its non-generic design. Received on Sat May 22 2004 - 06:55:39 CEST

Original text of this message