Hola usuario de nuestra página web, hallamos la solución a lo que buscas, desplázate y la obtendrás más abajo.
Solución:
Te sugiero que sigas la siguiente estructura:
nombre de la tabla: películas
movieid, título, trama, calificación, director
> sample data:
>
> 1 titanic Bollywood 10 James Cameron
nombre de la tabla: géneros
ID de género, género
> sample data:
> 1 Horror
> 2 Thriller
> 3 Action
> 4 Love
nombre de la tabla: géneros de películas
moviegenresid, movieid, ID de género
> 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 llama una relación de “muchos a muchos” y es muy común cuando se modelan categorizaciones del “mundo real”.
Existen muchas descripciones de cómo trabajar con tales relaciones, que incluyen:
- La respuesta de Praveen aquí, que es específica para su pregunta.
- http://en.wikipedia.org/wiki/Junction_table: la tabla adicional que une dos poblaciones en relaciones de muchos/mayores se suele denominar tabla de intersección o tabla de unión.
- http://www.tomjewett.com/dbdesign/dbdesign.php?page=manymany.php que muestra un ejemplo útil con la tabla y key/diseño de restricciones, un práctico diagrama de representación de datos en caso de que no esté claro, y cómo se modela y usa la relación en la aplicación.
- Cualquier buen libro/tutorial de diseño de bases de datos cubrirá esto en alguna parte.
No caiga en la tentación de omitir 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 “antipatrón” muy común que será causarte problemas, tal vez no hoy, tal vez no mañana, pero eventualmente. Recomiendo a cualquiera que trabaje con el diseño de bases de datos que lea “SQL Antipatterns” de Bill Karwin (http://pragprog.com/book/bksqla/sql-antipatterns). Está escrito de una manera que debería ser accesible para un principiante relativo, pero contiene mucho que aquellos de nosotros que deberíamos saber mejor necesitamos recordar de vez en cuando (relaciones de muchos a muchos, la solución de lista en un campo /problema, y lo que debe hacer en su lugar, son una de las primeras cosas que cubre el libro).
Esta respuesta es una elaboración de mi comentario sobre la respuesta anterior de @Praveen Prasannan.
Eliminaría el sustituto arbitrario keys movieID y genreID como una forma de eliminar la sobrecarga necesaria para la base de datos relacional. Ya que title y genre son naturales únicos keys, deberíamos usarlos y no pedirle a la base de datos que mantenga la unicidad de extra, sin sentido keys y mesas (la genres tabla en la respuesta referenciada). Esto debería mejorar la velocidad y el rendimiento de las grandes bases de datos relacionales y es una buena práctica.
nombre de la tabla: películas
primario key: título
título, argumento, calificación, director
> sample data:
> Titanic Bollywood 10 James Cameron
nombre de la tabla: géneros de películas
primario key: título, género
título, género
> sample data:
> Titanic Thriller
> Titanic Romance
Esto también facilita mucho las consultas 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.
Recuerda algo, que tienes permiso de decir si te fue útil.