Re: 2 people with same address - sometimes - standard data model?y

In article <l.carl.pedersen-1101951942230001_at_kip-2-sn-53.dartmouth.edu>, l.carl.pedersen_at_dartmouth.edu (L Carl Pedersen) writes:
> i need to track parents of students in order to send them certain mailings
> etc. my plan is to stick them into the same table that i use for student,
> as it already has all the columns i need etc. - so my table becomes a
> people table.
>
> my issue is this: some high percentage of these parents live together at
> the same address, but many do not (typically because they are divorced).
>
> for many reasons, it pains me to store *two* addresses when the addresses
> for two people are often the same.
>
> i suppose i could have some sort of "household" table that is referenced
> by the person table, but that seems sort of clumsy. one problem is that i
> can't think of an obvious external key to let my users jump between the
> two tables. i can't have my screens hide the fact that the addresses for
> two people are the same, since i need some way to *change* whether they
> are the same or not.
>
> oddly enough, none of our current systems seem to have any provision for
> representating the fact that two people have the same address.
>
> it seems to me this must be a very common data design problem - especially
> in the university environment.
>
> how do you solve this problem? is there a "standard" method?
>
> i should probably mention that these people are not *always* parents. in
> reality they are people who have cosigned for the student's loans and
> there may be zero to many of them. there is a good chance that the
> student may be living with their "parents" for a while, thus increasing
> the potential for duplication.
>
> if you send me email, i'll post a summary. thanks.

        Normalization of data would suggest setting up a "household" table. One possible unique key to this table would be the 9 digit zip code. It may be tedious and boring to update your current zip to 9 digits, but it may pay-off in the future.

Tim Crabtree Received on Thu Jan 12 1995 - 14:50:53 CET