1

Im trying to figure out what the appropriate way to setup a database would be given this scenario:

I am creating a Movie / TV database. A movie may have multiple genres and a tv show may have multiple genres.

Essentially what I am wondering is if you have a Movie table, TV table... should you:

  1. have a MovieHasGenre table consisting of a foreign key to the Movie table and a regular field for the genre value

    or

  2. have a MovieHasGenre table AND a Genre table where the MovieHasGenre has two foreign keys, one pointing to the Movie in the Movie table the other pointing to the Genre in the Genre table

Im really not sure if this is something standardized or just involves preference. Do we have concerns with speed as it seems removing the Genre table is one less join.

Community
  • 1
  • 1
Kairan
  • 5,342
  • 27
  • 65
  • 104

2 Answers2

1

Go with option 2.

It's useful to store each Genre once, and make reference to it via the MoveHasGenre table. That way, if you have other attribute columns for a genre, you don't have to store those attribute redundantly on each row where a given genre is mentioned.\

Re your comment:

Another case is if you want to change the spelling of a genre, and have it apply to all rows that reference it, with no chance you forget some.

Bill Karwin
  • 538,548
  • 86
  • 673
  • 828
  • I can see that for something like Cast, where you might want to have info about the cast (like age, etc) but I am still trying to figure out why I would want to do it for something like Genre where there really isn't anything more to add to the Genre table (at least nothing evident) - of course I am giving concrete example of a Movie database but applying this rational in general – Kairan Aug 29 '13 at 00:18
0

Option 2 is how you will normalize your data.

The problems with option 1 is data redundancy. Opposed to using a few bytes of data to store and INT you are using a potentially large value to store the name of the genre. The other problem like Bill said is that you have the potential for data inconsistency since you will have to update multiple fields if a genre changes instead of just one column.

However, what you have in option 1 is a denormalized version of option 2 which would have performance benefits over option 2 but I would imagine, given the seemingly small size of this database, that there won't be a significant performance change.

Carter
  • 332
  • 3
  • 13