Path: utzoo!utgpu!news-server.csri.toronto.edu!rpi!usc!elroy.jpl.nasa.gov!decwrl!deccrl!news.crl.dec.com!shlump.nac.dec.com!suisse.enet.dec.com
From: d_muller@suisse.enet.dec.com (Dan Muller)
Newsgroups: comp.object
Subject: Re: Has anyone taken an approach like this?
Message-ID: <21256@shlump.nac.dec.com>
Date: 19 Mar 91 21:20:06 GMT
References: <1991Mar19.042444.20834@netcom.COM>
Sender: newsdaemon@shlump.nac.dec.com
Reply-To: d_muller@suisse.enet.dec.com (Dan Muller)
Organization: Digital Equipment Corporation, Littleton, MA
Lines: 56

In article <1991Mar19.042444.20834@netcom.COM>, rodent@netcom.COM (Ben
Discoe) writes:
|
| <text deleted>
|
| I'd rather store the relationship once:
|
| Dog		"A eats B" relations	 Bird
| ----		--------------------	 ----
| ...		 ...........		 ...
| eats	->	DogOID/BirdOID	   <-	eaten by
|
| <text deleted>
|
|I'd be interested to know:
| 1. Has anyone ever seriously taken this approach?
| 2. Are there any obvious drawbacks?
| 3. This method seems appropriate for modeling anything from an encyclopedia
|to a rainforest to a coin collection.  Why can't I find anyone else pursuing
|it?  I've scanned all the papers and conference proceedings I can get my
|hands on.
| 4. Am I being foolishly naive and grossly underestimating the potential
|	difficulties?
|

I believe that in relational database theory, this organization of
data is used to form many-to-many relationships.  Treating Dog and
Bird as data tables, then the "A eats B" column is a special type of
data table called a "dictionary", and is in fact the _only_ way of
constructing many-to-many relationships between Dogs and Birds in a
properly normalized database system.

Given a Dog instance, you can look up all Bird instances eaten by the
Dog by searching the dictionary for entries containing that Dog's ID.

If you don't have a many-to-many relationship, then I don't think this
arrangement of the data gets you anything.

If there is a many-to-one relationship of Dogs to Birds, it's easier
to have Bird ID be part of the Dog object.

If there's a one-to-many relationship (a more likely situation in this
example), each Bird object can contain a Dog ID and all of a Dog's
meals can be found by searching for matching Dog IDs in the table of
Birds.

Of course, if you feel that a particular application can benefit from
treating the relationship itself as a separate object (for instance,
if the same type of relationship can hold among lots of unrelated
classes of objects and you wish to manipulate the relations per se
independently of the referenced objects), then the organization you
describe has obvious advantages.

--
| Dan Muller / KA1UXL / d_muller@took.enet.dec.com
| "So THAT's what an invisible barrier looks like!"