Re: Entity Overlap and Relationships
From: Bob Badour <bbadour_at_pei.sympatico.ca>
Date: Fri, 21 Apr 2006 00:17:45 GMT
Message-ID: <JwV1g.63425$VV4.1185214_at_ursa-nb00s0.nbnet.nb.ca>
>
>
> table People (...)
>
> table Parents (
> mother_id integer, foreign key to people, null if unknown
> father_id integer, foreign key to people, null if unknown
> child_id integer, foreign key to people
> )
>
> The other relations -- sibling, uncle, etc are derived from the
> Parents.
>
> BTW, you don't actually need the concepts of entity and relationship
> for designing a good database schema.
Date: Fri, 21 Apr 2006 00:17:45 GMT
Message-ID: <JwV1g.63425$VV4.1185214_at_ursa-nb00s0.nbnet.nb.ca>
Mikito Harakiri wrote:
> GB wrote:
>
>>2. What is the best way to handle people-people relationships (from a
>>schema perspective - I can see the sarcastic remarks now)? Has anyone
>>solved this problem of how to store {father, son, uncle, friend, etc.}?
>> Did you have to set up a trigger to update the table to include the
>>son relationship entry if the father relationship was added for
>>instance? Or would you just store the "parent" and "child" title for
>>the relationship, in this case "father" and "son" then the related
>>unique ID's for the people with the relationship?
>
>
> table People (...)
>
> table Parents (
> mother_id integer, foreign key to people, null if unknown
> father_id integer, foreign key to people, null if unknown
> child_id integer, foreign key to people
> )
>
> The other relations -- sibling, uncle, etc are derived from the
> Parents.
>
> BTW, you don't actually need the concepts of entity and relationship
> for designing a good database schema.
How does your proposed design capture 'friend' ? Even the obviously incomplete requirements included that. Received on Fri Apr 21 2006 - 02:17:45 CEST