Path: csiph.com!x330-a1.tempe.blueboxinc.net!feeder1.hal-mli.net!nx02.iad01.newshosting.com!newshosting.com!novia!news-out.readnews.com!transit3.readnews.com!news-out.news.tds.net!newsreading01.news.tds.net!86597e80!not-for-mail From: "Arved Sandstrom" Subject: Re: Designing a structure Message-ID: X-Comment-To: comp.databases,comp.lang. Newsgroups: comp.lang.java.databases In-Reply-To: References: Content-Type: text/plain; charset=IBM437 Content-Transfer-Encoding: 8bit X-Gateway: time.synchro.net [Synchronet 3.15a-Win32 NewsLink 1.92] Lines: 63 Date: Wed, 27 Apr 2011 15:21:33 GMT NNTP-Posting-Host: 96.60.20.240 X-Complaints-To: news@tds.net X-Trace: newsreading01.news.tds.net 1303917693 96.60.20.240 (Wed, 27 Apr 2011 10:21:33 CDT) NNTP-Posting-Date: Wed, 27 Apr 2011 10:21:33 CDT Organization: TDS.net Xref: x330-a1.tempe.blueboxinc.net comp.lang.java.databases:63 To: comp.databases,comp.lang. "Stefan Ram" wrote in message news:database-20080503180716@ram.dialup.fu-berlin.de... > David Segall writes: >>For most purposes I want to communicate with a family or >>business at its "home" address. For example, "Fred and Betty >>Bloggs" or "Acme Widgets" have a specified street address and >>telephone number. It is possible that the Bloggs family has a >>holiday house or I have to deal with Acme Widgets at more than >>one location. > > If a family can have n houses, that is a 1:n-relation, and its > implementation is being described in every RDBMS textbook. > >>I also need information about individuals such as mobile phone >>numbers and birthdays but I don't want to duplicate shared home >>and business addresses and telephone numbers. For example, >>Betty Bloggs could work for Acme Widgets and share a town house >>and a country house with Fred. > > Then have one table for persons, one for houses and one for > the n:m-relation (standard textbook material). > >>have been frustrated by the address books in many applications >>that insist you supply all the details for every individual. > > If you do not want a field to be mandatory, you are free > to design so. > > Just design which entities and relations you want to > model and which attributes are mandatory and which not. > Then implement this and you are done. I tend to agree. The basic entities are fairly clearcut: addresses, personal (individual/business) info, phone numbers, email addresses. There are simply going to be lots of relationships, and in addition they are going to be named relationships (so one can designate a work phone number as opposed to a personal phone number, or a primary home address as opposed to a cottage), so the join tables will often have at least one extra attribute. As far as people sharing addresses, say, like a couple. Well, that's not really a database problem, per se. The address itself only needs to be stored once - there will simply be two PersonInfo-Address relationships. To avoid having to enter the data twice is really more a function of the application that one designs to enter (and display) the data. In other words, I'd write the application so that it is quite flexible at searching/retrieving entities and allowing new links (relationships) to be established. Myself I would keep personal relationships (e.g. couple, family, roommates etc) entirely separate. That is, if you want to say that Person A is married to Person B, use a separate join table for that. Because personal relationships do not invariably imply any other linkages. To recap, I see most of the work being asociated with the interface, not the actual database. AHS --- * Synchronet * The Whitehouse BBS --- whitehouse.hulds.com --- check it out free usenet! --- Synchronet 3.15a-Win32 NewsLink 1.92 Time Warp of the Future BBS - telnet://time.synchro.net:24