Solución:
Te sugiero que sigas la siguiente estructura:
tablename: películas
movieid, título, trama, clasificación, director
> sample data:
>
> 1 titanic Bollywood 10 James Cameron
tablename: géneros
genreid, género
> sample data:
> 1 Horror
> 2 Thriller
> 3 Action
> 4 Love
tablename: moviegenres
moviegenresid, movieid, genreid
> sample data:
> 1 1 2
> 2 1 4
Y la consulta es:
select m.*,group_concat(g.genre)
from movies m inner join moviegenres mg
on m.movieid=mg.movieid
inner join genres g
on g.genreid=mg.genreid
group by m.movieid
;
Ver el violín
Lo que busca modelar aquí se denomina relación “muchos a muchos” y es muy común cuando se modelan categorizaciones del “mundo real”.
Existen muchas descripciones sobre cómo trabajar con tales relaciones, que incluyen:
- La respuesta de Praveen aquí, que es específica de su pregunta.
- http://en.wikipedia.org/wiki/Junction_table: la tabla adicional que une dos poblaciones en muchas relaciones / mayo se suele llamar tabla de intersección o tabla de unión.
- http://www.tomjewett.com/dbdesign/dbdesign.php?page=manymany.php que muestra útilmente un ejemplo con la tabla y el diseño de claves / restricciones, un práctico diagrama de representación de datos en caso de que no esté claro, y cómo la relación se modela y se utiliza en la aplicación.
- Cualquier buen libro / tutorial de diseño de bases de datos cubrirá esto en alguna parte.
No se sienta tentado a saltarse la tabla de intersección adicional almacenando varios géneros en un campo para cada película (una lista separada por comas, por ejemplo). Este es un “anti patrón” muy común que voluntad causarte problemas, tal vez no hoy, tal vez no mañana, pero eventualmente. Recomiendo a todos los que trabajen con el diseño de bases de datos que lean “SQL Antipatterns” (http://pragprog.com/book/bksqla/sql-antipatterns) de Bill Karwin. Está escrito de una manera que debería ser accesible para un principiante relativo, pero contiene mucho que aquellos de nosotros que deberíamos conocer mejor debemos recordar de vez en cuando (relaciones de muchos a muchos, la solución de lista en un campo / problema, y lo que debería hacer en su lugar, es una de las primeras cosas que cubre el libro).
Esta respuesta es una elaboración de mi comentario sobre la respuesta de @Praveen Prasannan anterior.
Eliminaría las claves sustitutas arbitrarias movieID y genreID como una forma de eliminar la sobrecarga necesaria para la base de datos relacional. Ya que title y genre son claves naturales únicas, debemos usarlas y no pedirle a la base de datos que mantenga la unicidad de claves y tablas adicionales y sin sentido (la genres tabla en la respuesta referenciada). Esto debería mejorar la velocidad y el rendimiento para grandes bases de datos relacionales y es una buena práctica.
tablename: películas
clave principal: título
título, trama, clasificación, director
> sample data:
> Titanic Bollywood 10 James Cameron
tablename: moviegenres
clave principal: título, género
título, género
> sample data:
> Titanic Thriller
> Titanic Romance
Esto también hace que las consultas sean mucho más fáciles tanto para el usuario como para la máquina, ya que no tiene que unirse a una tabla adicional para decodificar los géneros por el UID arbitrario.