[AccessD] Design Question

Being a normalization freak, my take would be a thrice of tables, Contacts
and ContactRelationships and Relationships, the intermediate table being
associative (i.e. M-M). Then in case a new relationship evinces, you are
covered by simply adding a row to Relationships and populating the
associative table appropriately.
If you are absolutely sure that no other relationships can evolve other than
the two stated, then my proposal is overkill. Assuming this, then you need a
column (YesNo) for each of the two relationships. You queries will then need
to anticipate either or both.
HTH,
Arthur

-----Original Message-----
From: accessd-bounces at databaseadvisors.com
[mailto:accessd-bounces at databaseadvisors.com] On Behalf Of Josh McFarlane
Sent: November 14, 2005 12:38 AM
To: Access Developers discussion and problem solving
Subject: [AccessD] Design Question

Hey guys got a quick question about design.

I'm making a database for a non-profit service organization I'm
working for. There's going to be membership data per person, however,
at the same time the person may be a contact to an external
organization for part of their projects, or it may be some completely
unrelated person.

Here's my question:

Should I have only one table, called say People, or should I have two
seperate tables of data: Members and Contacts?

Option A would require intermediate tables linking anything to the
people table, but Option B would maintain duplicate data for members
that are also in external contact organizations.

Any suggestions?

Thanks!
--
Josh McFarlane

"Peace cannot be kept by force. It can only be achieved by understanding."
-Albert Einstein
-- 
AccessD mailing list
AccessD at databaseadvisors.com
http://databaseadvisors.com/mailman/listinfo/accessd
Website: http://www.databaseadvisors.com