NYCPHP Meetup

[Greg Wilson]

how about:

a table of people
 - id, firstname, lastname, etc

a table of movies
 - id, title, etc

a table of roletypes
 - director, producer, actor, cinematographer, etc

and a table relating people to movies based on roles
 - movie_id, people_id, roletypeid

greg


On Fri, 2004-01-09 at 10:23, Keith J Richardson wrote:
> I would personally have a table of people. Then have a table of say peopletypes, which would be producer, director, acter, etc
> 
> then in the people list, they have a peopletypeid, which is the unique id of the peopletype that is in the other list
> 
> -----Original Message-----
> From: talk-bounces at lists.nyphp.org
> [mailto:talk-bounces at lists.nyphp.org]On Behalf Of Matthew Zimmerman
> Sent: Friday, January 09, 2004 10:24 AM
> To: NYPHP Talk
> Subject: [nycphp-talk] Database Relation Question
> 
> 
> Is it considered good database design to have two tables related to 
> each other through more than one field.
> 
> What I means is I have two tables. One is called "movies" and one is 
> called "people".
> 
> Movies has some fields like "director, producer, cinematographer".  
> People is just a list of people "first_name, last_name, etc."
> 
> Is it ok for movies to relate to people via "director" and "producer" 
> and "cinematographer" or is it better to create a "producer" table to 
> related to producer, "director" table to relate to director, etc.
> 
> I have a feeling I am doing it the right way just having a "people" 
> table but I wasn't sure if this would cause any query problems down the 
> line.
> 
> Thanks for your help. I am not sure if I used all of the proper 
> terminology here so I can rephrase the question if needed.
> 
> Matt
> 
> _______________________________________________
> talk mailing list
> talk at lists.nyphp.org
> http://lists.nyphp.org/mailman/listinfo/talk
> _______________________________________________
> talk mailing list
> talk at lists.nyphp.org
> http://lists.nyphp.org/mailman/listinfo/talk
>