[AccessD] A database design for contacts....

Your solution is precisely what I implied but I guess I didn't say. And the
same solution cascades down to the addresses.

Arthur


On 5/9/07, Charlotte Foust <cfoust at infostatsystems.com> wrote:
>
> I agree and disagree, Arthur.  In some databases, like membership
> databases, there are categories of membership which include persons or
> organizations.  The organization may not provide a contact, but it still
> has an address and phone number, so it still needs to be recorded,
> particularly if it pays dues or makes contributions.  Persons are all
> contacts, but not all of them may be associated with an organization.
> The same rationale holds true in a "family" database, except that all
> families will have at least one person in them at some point in their
> existence.
>
> You can address the problem in part by using a DBMember table that
> contains a unique key for each organization or person + a membertype
> value.  The PK of that table would become the PK of the organization or
> person table records.  You would need a separate table to make the
> connections between person and organization, and some way to indicate
> whether a person is the primary contact for that organization.
> Addresses, phone numbers, etc. would be linked to the DBMember and would
> include a field to categorize them (home, mailing, office, etc.).
>
> Charlotte Foust
>