I am creating a movies website... I have to display information on each movie, including genres, stars, and lots of info (IMDB.com like)...

I produced a 'movies' table including an ID plus some fundamental information. For that genres I produced a 'genres' table including 2 posts: ID and genre. I Quickly make use of a 'genres2movies' table with two posts:movieID and also the genreID, for connecting between your genres and also the movies tables...

By doing this, for instance, if your movie have 5 different genres I recieve the movieID in five different rows of the'genres2movies' table. Its much better than such as the genre every time for every movie but...

There's an easy method for carrying this out???

I have to do that moreover stars, languages and nations so performance and database dimensions are vital.


It may sound as if you are following proper normalisation rules right now, which is what you would like.

However, you might find when performance is really a main factor you might want to p-normalise certain parts of the data, since JOINs between tables are relatively costly procedures.

It's often a trade-off between proper/full normalisation and gratifaction

You're in the best track. That's the best way to do many-to-many associations. Database size will not grow much since you use integers as well as for speed you have to setup correct indexes for individuals IDs. When creating Choose queries browse the EXPLAIN - it will help to obtain the bottlenecks of speed.

You are on precisely the right track - this is actually the correct, stabilized, approach.

The only real factor I'd add is to make sure that your index around the join table (genres2movies) includes both genre and movie id which is generally useful (based upon the chooses used) to define indexes both in directions - ie. two indexes, purchased genre-id,movie-id and movie-id,genre-id. This guarantees that any range choose on either genre or movie will have the ability to make use of an index to retrieve all of the data it requires without having to turn to a complete table scan, or even need to access the table rows themselves.