Re: Relational and multivalue databases

"Marshall Spight" <mspight_at_dnai.com> wrote in message news:_1c_b.369115$I06.3888698_at_attbi_s01...
> "Dawn M. Wolthuis" <dwolt_at_tincat-group.com> wrote in message
news:c1agf7$v53$1_at_news.netins.net...
> >
> > Sure, but what do you want to do, Dave -- get a random identifier for
each
> > phone number and then since people have more than one have a link tabke
that
> > links people with each of the keys to their phone numbers? I guess that
> > might make sense to someone in the RDBMS world, but step back a minute
and
> > look that -- the not-terribly-technical-term "silly" comes to my mind.
>
> That argument may carry some weight when the data type involved, a phone
> number, is approximately the same size as a foreign key. For example,
> one could imagine using the phone number itself as the key to the
> phone numbers table (it is unique, after all) and at that point, there's
> no value to the association table any more.
>
> But that argument stops working as soon as the amount of information
> grows a bit. Consider even something as simple as addresses. They
> aren't all that much more complicated than a phone number: line1,
> line2, city, state, zip. Repeating that in the person record for each
> person at the house isn't efficient, and it makes correcting typographic
> errors more error-prone. (One can imagine each person in the house
> having the same address but with the street spelled differently.)
>
> For my personal experience, the day someone explained association
> tables to me was the first day that I began to think that the database
> world might really have something interesting to say. (This was some
> time ago, but I still remember the exact moment of realization.) It
> is a significant achievement, and I know of no other system that has
> something that handles many:many relationships as well. Certainly
> no OO language, for all the emphasis on container classes, has ever
> handled them as well.

Yes, Marshall, you are right that I answered the specific instance and not a generalization. When it comes to addresses, they are many-to-many with people, while 1-1 with places (if we can make the assumption that each place has one and only one address). I know the language I'm about to use doesn't play well with the RDBMS theorists, but I would think of my entities as people, places, and things. Addresses go with a "Places" entity, perhaps named "Addresses".

So, we have people and we have addresses with a M-M relationship. In a PICK model, the implementation would likely include a PEOPLE function and an ADDRESSES function (called "files"). The PEOPLE function would map to a list of ADDRESSES identifiers. Two files with a link between them.

Often the implementation would include return-links to improve performance if there would be queries not just about what addresses a person has, but also who lives at a particular address. Then extensions could be made to the vocabulary of each function so that queries like this would be the norm:

LIST PEOPLE FULL-ADDRESSES LIST ADDRESSES FULL-NAMES This is a different approach to creating a VIEW with COLUMNS from each TABLE against which the user would query. In the case of the RDBMS, we then come up with a new vocabularly for an entity, while often retaining the names of the attributes. PICK lets the user of the database think of each file/function as a portal into the database, increasing the language for that file/function but not altering the name of the file unless there is some purpose to doing so. Each "view" in PICK looks through the eyes of one of the implemented functions (files).

This approach is much more like the web, where there are documents with links to other documents, which might then have return links to all docs that point to them. Part of the charm is in the simplicity of the approach.

--dawn Received on Mon Feb 23 2004 - 04:19:41 CET