Re: Similar data, sharing tables

This way also seems to be better suited to OO programming when it comes time to develop a front end application (if there is gong to be one :) ).

Since a COACH and PLAYER are also a TYPE_OF PERSON, it seems to make sense. Might make it simpler to extend latter when you start to make additions like REFEREES. "Heinz Huber" <hhuber_at_racon-linz.at> wrote in message news:3BAADD22.B7F8F922_at_racon-linz.at...
>
>
> Harlan Messinger wrote:
> >
> > Suppose I've got the following tables for secondary school athletic
teams:
> >
> > TEAM
> > teamID
> > teamName
> > organizationName
> > address
> > city
> > state
> > zip
> > phone
> >
> > PLAYER
> > playerID
> > teamID
> > playerName
> > nickName
> > address
> > city
> > state
> > zip
> > phone
> > age
> > grade
> > position
> >
> > Now suppose I need to start storing information about each team's coach.
> > The information required for a coach is *similar* to the information
> > required for a player. But I don't need a coach's age, and grade and
> > position are not applicable. On the other hand, I want the name of the
> > coach's university.
>
> [snip]
>
> I'd do it that way:
>
> PERSON
> personID PK
> personName
> nickName
> address
> city
> state
> zip
> phone
>
> PLAYER
> personID PK, FK
> teamID PK, FK
> age
> grade
> position
>
> COACH
> teamID PK, FK
> personID FK
> university
>
> The question is what to make the PK in COACH table. A team can only have
one
> coach, so that seems to be the right column.
>
> If you can pull university into the PERSON table, you could omit the COACH
table
> completely and add a personIDCoach to TEAM.
>
> Since you can change the structure of the database (as you have pointed
out in
> you mail later), the change should be possible. The migration of the data
from
> PLAYER to PERSON should be pretty straight forward.
>
> hth,
> Heinz
Received on Mon Oct 08 2001 - 18:58:11 CEST