Re: Nearest Common Ancestor Report (XDb1's $1000 Challenge)
Date: Sat, 22 May 2004 15:19:40 +0200
Message-ID: <kehua0ds4jjr9km7sm6d6fa5m3a6aktb0u_at_4ax.com>
On 21 May 2004 21:55:39 -0700, Neo wrote:
>> 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
Of course I did. That's how the relational model works.
>The relationship between a table and its records is that of class and
>it's instances.
You're right, but that's the internals of a database. What matters is the semantics of my implementation, not the internals. I'm well aware that confusion may arise from the fact that the word "class" in your quote above is the same as the word "class" in messages about the semantics of the challenge, yet they are completely distinct things.
I've worked on projects that required me to switch from the problem level to the meta-level (where you can have a table named columns and a column named tablename) and even to the meta-metalevel (where the one of the values in the column tablename is column). Gives you major headaches in the beginning, but you get used to it - the headaches get less, though they never disappear completely <g>.
> 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.
Of course not. It's a relational structure, the original structure was an XDb1 kind of structure. But the structure is not relevant, the semantics are. And that's where we're getting with your next sentence:
> Thus the provided
>solution, has no way to determine that john is a person and that fido
>is a dog.
SELECT things.thing, types.type FROM things LEFT OUTER JOIN types ON types.thing = things.thing
Wow! I never thought that I would have to teach XDb1's lead developer how to write a join.
(When I chose the names "types" and "type" for that table and column, I didn't yet know that you thought of it as classes. If I were to rewrite my implementation now, I'd choose to call the table classes and the column class).
> 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.
Two things can't be called the same. Why do I need to repeat this over and over again?
> Its not a big problem, I know you could fix it.
It's not a problem. It doesn't need fixing.
>>[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.
The table name is part of the intension, not part of the extension.
>Being
>explict is not equivalent to being redundant.
In this case it is.
>> [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.
It can, by joining the types table to the things table. Even though SQL is not the best tool for formatting, I can even produce the indented report from the data in my tables:
select case
when thing is null then type
else case
when type is not null then ' '
else ''
end + coalesce(thing, '')
end
from
(select types.type, things.thing
from things
left join types on types.thing = things.thing union
select types.type, null
from types) as derivedtable
order by type, thing
> 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'.
In my database, 'john isa thing' is not stored either, because it can be derived. Everything is a 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.
See above.
>> >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.
To summarize:
* At present, my relational model does not allow two things to have the
same name; the XDb1 model does allow this but you have to use an
undocumented "feature" to enter your data and your reports are instantly
rendederd worthless.
* If needed, my relational model can easily be adapted to allow two or
more things to have the same name and enhance the reports so as to still
be meaningful, whereas users of XDb1 will have to wait until XDb1's
developers get around to changing this and are stuck in the meantime.
This once again proves that my relational implementation is indeed not "as flexible" as the XDb1 implementation, but *more* flexible.
If the original message had indicated that different things might have the same name, I would of course have incorporated that in my design. But seeing how XDb1 fails to address this issue correctly, I can see why you did not include that in your original post.
>> >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.
It's actually quite easy to add the class to the report, if that's what you want - just left join the types table. But your original post and the web page mentioned therein didn't ask for inclusion of the class on the report.
This has of course nothing to do with allowing or disallowing things with the same name. I don't know why you're trying to create a connection here.
Best, Hugo
-- (Remove _NO_ and _SPAM_ to get my e-mail address)Received on Sat May 22 2004 - 15:19:40 CEST