Re: confusing relationships
- From: "Allen Browne" <AllenBrowne@xxxxxxxxxxxxxx>
- Date: Wed, 22 Mar 2006 15:12:44 +0800
The answer to your question will depend what you need to store.
Using the example from:
http://allenbrowne.com/AppHuman.html
you could create a group of type "marriage", with 2 people in
tblGroupClient. If you want to track the full history of a person's
marrigage, these groups will need to be limited by date, i.e. the marriage
started on m/d/y and ended on m/d/y (blank if still current.) You will also
need BirthDate and DeathDate fields in tblClient, and based on all those
dates you could then retrieve the name of the person's current spouse(s).
--
Allen Browne - Microsoft MVP. Perth, Western Australia.
Tips for Access users - http://allenbrowne.com/tips.html
Reply to group, rather than allenbrowne at mvps dot org.
"kingnothing via AccessMonster.com" <u18754@uwe> wrote in message
news:5d9f85ab18158@xxxxxx
Thanks Allen for your lightning fast reply...
Yeah, now its making more sense to me....i wuold rather have it the way
you
have said..but how does that solve the issue of a contact having multiple
spouses....and multiple children??
You have to excuse me if its a dumb question....i'm no software
designer...
Allen Browne wrote:
Not sure I would use separate tables for contact, spouse, and child.
It seems to me that these are people who could have policies in their own
right, so it makes more sense to me to put all the people in a single
table
with a ClientID primary key. Your Insurance table would then contain
foreign
keys for:
PolicyHolderID relates to Client.ClientID
Spouse relates to another record in Client table.
...
If one person has multiple policies, it might make sense to just have the
PolicyHolderID foreign key field in the Insurance table, and have all the
other family information in a different table. For a downloadable example
of
how that might work, see:
People in households and companies - Modelling human relationships
at:
http://allenbrowne.com/AppHuman.html
.
- Follow-Ups:
- Re: confusing relationships
- From: kingnothing via AccessMonster.com
- Re: confusing relationships
- References:
- confusing relationships
- From: kingnothing via AccessMonster.com
- Re: confusing relationships
- From: Allen Browne
- Re: confusing relationships
- From: kingnothing via AccessMonster.com
- confusing relationships
- Prev by Date: Re: confusing relationships
- Next by Date: Re: confusing relationships
- Previous by thread: Re: confusing relationships
- Next by thread: Re: confusing relationships
- Index(es):
Relevant Pages
|