Re: Relational and multivalue databases
Date: Mon, 23 Feb 2004 00:44:46 GMT
Message-ID: <_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.
Marshall Received on Mon Feb 23 2004 - 01:44:46 CET