Re: why hierarchy?

Neo wrote:
> > So If I had three propositions:
> > "John is friends with Frank at Work"
> > "Bob is friends with Sam at Home"
> > "Tommy is friends with Billy at School"
> > and (ignoring the bidirectionality for clarity), they would generate:
> >
> > [ john ] -- [ [ friend ] --- [ at ] --> [ work ] ] --> [ frank ]
> > [ bob ] -- [ [ friend ] --- [ at ] --> [ home ] ] --> [ sam ]
> > [ tommy ] -- [ [ friend ] --- [ at ] --> [ school ] ] --> [ billy ]
> >
> > Now in an RDB I might have a corresponding Friendships relation:
> >
> > Person Friend Location
> > ----------------------------------
> > john frank work
> > bob sam home
> > tommy billy school
> >
> > For an RDB a simple question like "Which people have friends some place
> > other than at home" requires a statement something of the order of:
> >
> > SELECT Person from Friendships WHERE Location != "home"
>
> Currently dbd's select expression doesn't implement NOT EQUAL TO and
> would requires interfacing to the db via its API and looping thru
> things.
>
> Following expression finds a person that has a friend at home that is a
> person:
> (and (select person instance *)
> (select * (select friend at home) (select person instance *)))

Well okay we have got somehow neo. I appreciate your honesty and responses to my questions. Hopefully we can now agree that in the case of query formulation the RM has an advantage of your system, comparing:

SELECT Person from Friendships where Location != "Home"

with something that would of the nature of the following statement, but with even greater complication due to the extra loops involved:

(and (select person instance *)

        (select * (select friend at home) (select person instance *)))

The arguments I have put to you are analagous to the ones of the great debate between Codds RM and CODASYL, that relational theory won handsomely. Your queries will always be more complex because you have created a navigational model. I'd like, if you had chance, for you to read:

http://www.intelligententerprise.com/db_area/archives/1999/991105/online2.jhtml;jsessionid=4J3MNANICW05WQSNDLRCKHSCJUNN2JVN

which explains this old kettle of fish a great deal better than I could.

>
> Following expression finds a person that has a friend at home. The
> friend could be anything (ie dog, cat, etc).
> (and (select person instance*)
> (select * (select friend at home)))
>
> I can use this example to show how dbd is less impacted by new data
> requirements. Suppose the friend can be things other than people and
> each type requires different attributes. Or suppose the locations are
> of different types and require different tables. Or suppose we need to
> relate data to Person (not a person), Friend (not a friend), or
> Location (not a location). For example, that friend and enemy are
> opposites. Or suppose the verb can be "friend before work", "friend
> after work", "friend at gym", etc. Or suppose, John is friends with Bob
> between 1PM to 5PM. Allowing for such flexibility in RMDB will impact
> the schema severely, but has little to no impact in dbd.

Now flexibility in the form of having no schema is a different matter altogether, and it is fine to have that whole different debate *so long* as one has accepted that the navigational models have weaknesses in query formulation compared to RM.

I hope this has been helpful to you - I have attempted to engage you seriously, and hope that you can move forward with your work in light of what I have learnt in the past too.

I also highly recommend you get a copy of "Data and Reality" by William Kent off amazon as there is some really illuminative stuff in there. Received on Tue Aug 01 2006 - 14:40:56 CEST