Re: Entity Overlap and Relationships

From: Bob Badour <bbadour_at_pei.sympatico.ca>
Date: Tue, 18 Apr 2006 13:29:21 GMT
Message-ID: <RQ51g.61669$VV4.1151927_at_ursa-nb00s0.nbnet.nb.ca>


GB wrote:

> 1. What is the "industry best practice" in the following situation:
>
> Say there are 3 types of entities {Entity1, Entity2, Entity3}
>
> Each Entity type has unique attributes and similar ones.
>
> For the attributes that are unique to each Entity it is easy (either
> they are in the table with the Entity or in the case of a one-to-many
> relationship there is a table related only to that Entity).
>
> In the case where there are similar attributes (i.e. each Entity has
> multiple addresses - all of the same form { addressline1, addressline2,
> city, state, zip, etc }) what is the proper way to handle this? I was
> thinking of creating the following tables for each entity:
> Entity1Address, Entity1Phone, Entity2Address, Entity2Phone,
> Entity3Address, Entity3Phone with the Address and Phone tables all the
> same but related only to the relevant Entity table but something rubs
> me the wrong way here...
>
>
> 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?

With all due respect, the answers to your questions will depend on the myriad requirements you have not mentioned. Anyone who pretends to have answers is a crank. Received on Tue Apr 18 2006 - 15:29:21 CEST

Original text of this message