Re: Designing a structure for a personal database

David Segall <david@[EMAIL PROTECTED]
> 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.