una - como hacer un buscador sencillo usando php y mysql

¿Cómo diseñar una base de datos de películas? (10)

Intento entender cómo funcionan estas cosas alucinantes que llaman Database Design sin mucho éxito, así que intentaré ilustrar mi problema con un ejemplo.

Estoy usando MySQL y aquí está mi pregunta:

Supongamos que quiero crear una base de datos para guardar mi colección de DVD. Tengo la siguiente información que quiero incluir:

Título de la película
Actores
Tiempo de ejecución
Género
Descripción
Año
Director

Me gustaría crear relaciones entre ellos para hacerlo más eficiente pero no sé cómo.

Esto es lo que estoy pensando para el diseño de la base de datos:

Films Table => filmid, filmtitle, runningtime, descripción

Año Tabla => año

Género Table => género

Director Tabla => director

Actores Table => actor_name

Pero, ¿cómo podría crear relaciones entre estas tablas?

Además, he creado una identificación única para la tabla de películas con una clave principal que se incrementa automáticamente, ¿necesito crear una identificación única para cada tabla?

Y finalmente, si tuviera que actualizar una nueva película en la base de datos a través de un formulario PHP, ¿cómo insertaría todos estos datos (con las relaciones y todo?)

gracias por cualquier ayuda que puedas dar, Keith

He creado una identificación única para la tabla de películas con una clave principal que se incrementa automáticamente, ¿necesito crear una identificación única para cada tabla?

Sí, cada tabla debe tener una identificación única. Pero, esa no es necesariamente la clave principal de incremento automático, es lo que hace que esa instancia particular sea única. Por ejemplo, para películas, creo que es común ser título + año de lanzamiento, aunque querría consultar con un aficionado a la película (un experto en dominios) para estar seguro de eso. El incremento automático es una alternativa, básicamente, cuando realmente no tiene nada más para singularizar.

Puede usar una tecla de incremento automático para facilitar el uso en combinaciones y cosas así, pero debe tener una restricción única en los campos de exclusividad de todos modos.

En cuanto al diseño real, sugeriría algo como:

Films => Primary Key(filmid), Unique Constraint(filmtitle, year), runningtime, description, Foreign Key(Genre), Foreign Key(DirectorId) Genre Table => Primary Key(Genre) Director Table => Primary Key(DirectorId), DirectorName Actors Table => Primary Key(ActorId), ActorName Films_Actors => Primary Key(Foreign Key(ActorId), Foreign Key(FilmId))

Para el inserto, bueno, francamente, es un PITA. Debe insertar en orden inverso (y aquí es donde las teclas de incremento automático pueden ser un PITA aún mayor; si puede agregar una fecha de nacimiento o algo en la tabla Actores y Directores, entonces una restricción única puede facilitarlo).

Entonces, insertarías actor (es), director, película y luego Films_Actors. Idealmente, todo en una sola transacción. Además, supongo que el género ya está completo, y es una lista de selección, por lo que no es necesario insertarlo.

A veces los actores son directores y viceversa, ¿tal vez quieres una mesa de "personas"?

Cada tabla debe tener una clave principal que sea única.

Deberías leer sobre la normalización de la base de datos .

Una tabla anual probablemente sea innecesaria.

Si es el año de lanzamiento, por ejemplo, entonces el año se puede almacenar en la película.

Si hay múltiples directores en una película, entonces tendrías una mesa separada que mantendría la clave principal de la mesa de la película y la mesa del director. De forma similar para cualquiera de las restricciones de clave externa que son muchas a una o muchas a muchas. En particular, creo que esto se aplicaría al Actor.

Estas son las tablas que usaría:

films (_id_, title, runningtime, description) genres (_id_, name) people (_id_, name, birthdate, etc...) roles (_roleid_, rolename) filmgenres (_filmid_, _genreid_) castandcrew (_filmid_, _roleid_, _personid_)

En lugar de tener una mesa de directores y actores, solo tiene una mesa de personas. Esto también puede incluir a los miembros de la tripulación (en caso de que quieras rastrear quién era el 2º asistente juvenil Dolly Grip). Cada película puede ser de cualquier cantidad de géneros (comedia y terror, por ejemplo). Además, la gente puede tomar cualquier número de roles en cada película, hay un buen número de actores / directores por ahí.

La tabla Roles no significa necesariamente el personaje que el actor está jugando, pero podría. Podría ser "Director", "Productor", "Actor" ... o incluso "Luke Skywalker" si quisieras obtener ese grano fino ... Creo que IMDB lo hace.

Es de esperar que los nombres de los campos anteriores sugieran las claves externas, y he puesto _underscores_ alrededor de las claves principales que usaría.

La tabla Films también necesita enlaces a las tablas de género, director y actores. Dado que los actores, al menos serán muchos para muchos (una película mostrará más de un actor, un actor estará en más de una película), necesitará una tabla para vincularlos.

Films Table => filmid, filmtitle, runningtime, description, genreid, directorid Genre Table => genreid, genre Director Table => directorid, director Actors Table => actorid,actor_name FilmActor link table => actorid, filmid (with a record linking each actor to each film)

Cualquier tabla que pueda ser muchas a muchas necesita una tabla de enlaces.

Lo que sigue no es un código MySQL real. Parece que lo que necesitas es más bien un comienzo conceptual aquí. Así que aquí hay un modelo de cómo debería ser su base de datos.

Mesa de actor

id (clave principal)
nombre de pila
apellido
etc. (cualquier columna adicional que quiera almacenar en un actor)

Mesa del director

carné de identidad
nombre de pila
apellido
etc.

Mesa de género

carné de identidad
nombre
etc.

Mesa de cine

carné de identidad
título
descripción
tiempo de ejecución
fecha de lanzamiento
ID de director: esta es una clave externa que hace referencia a la identificación (la clave principal) del director que dirigió la película
id. de género: como la identificación del director, esto se refiere a la identificación del género al que pertenece la película

Tabla de índice Actor-película

identificador de película: esta es una clave externa que hace referencia a la identificación de la película
ID de actor: esta es una clave externa que hace referencia al ID de un actor en la película.

Para cada actor de la película, agregaría una fila al Actor-Film Index. Entonces, si los actores 5 y 13 (las claves principales para esos actores) protagonizaran la película 4 (otra vez, la clave principal para esa película), tendrías dos filas que reflejarían ese hecho en tu índice: uno con id. De película = 4, y el actor id = 5, y otro con película id = 4, y el actor id = 13.

Espero que ayude.

Además, esto supone que cada película tiene exactamente un director. Si alguna película en su biblioteca tiene dos directores (como Slumdog Millionaire), le conviene separar la identificación del director de la mesa cinematográfica y crear un índice Director-Film como el Actor-Film Index como se indica más arriba.

Me doy cuenta de que su pregunta ya ha sido respondida, sin embargo, quería señalarle:
http://www.imdb.com/interfaces

IMDB proporciona archivos de texto plano de su base de datos (menos claves principales). Puede encontrar esto útil para completar su base de datos una vez que se pone en marcha, o puede usarla en su programa / sitio web para permitirle simplemente buscar un título de película para agregar a su "Colección de DVD", y tener el resto de la información sacado de estos.

Puede descargar el esquema Imdb here .

Realmente no necesitas una YearTable, y todo lo que necesitas es una columna genre_id, director_id y actor_id en tu tabla de películas.

Además, las tablas de género, director y actor necesitan sus propias identificaciones únicas.

Editar: Esto es, por supuesto, asumiendo que solo vas a tener 1 género, director y actor para cada película. Lo cual probablemente no es el caso.

Para tener muchos actores que pertenecen a muchas películas, necesitarás una tabla de relaciones separada. Podrías llamarlo "moviesActors" (o actoresMovies) y cada fila tendrá un actor_id y un movie_id para decir que este actor estuvo en esta película .

Tienes que hacer una distinción entre atributos y entidades. Una entidad es una cosa, generalmente un sustantivo. Un atributo es más como una pieza de información descriptiva. En la jerga de la base de datos, entidad = tabla, atributo = campo / columna.

Tener una tabla separada para ciertas cosas, usemos el director, como ejemplo, se llama normalización. Si bien puede ser bueno en algunas circunstancias, puede ser innecesario en otros (ya que generalmente hace las consultas más complicadas, tienes que unir todo, y es más lento).

En este caso, no es necesario tener una tabla de año, ya que no hay otros atributos de un año, además del año en sí, que almacenaría. Es mejor desnormalizar esto y almacenar el año en la mesa de la película.

Director, por otro lado, es diferente. Tal vez desee almacenar el nombre, apellido, fecha de nacimiento, fecha de fallecimiento (si corresponde), etc. del director. Es obvio que no desea ingresar la fecha de nacimiento del director cada vez que ingresa en una película que esta persona dirige, entonces tiene sentido tener una entidad separada para un director.

Incluso si no desea almacenar toda esta información sobre el director (solo desea su nombre), tener una tabla separada para ello (y usar una clave sustituta - Lo haré en un segundo) es útil porque previene los errores tipográficos y los duplicados: si el nombre de alguien se deletrea mal o se ingresa de manera diferente (primero, último frente al último, primero), entonces si intenta buscar otras películas que haya dirigido, fracasará.

Usar una clave sustituta (clave principal) para tablas generalmente es una buena idea. Hacer coincidir un número entero es mucho más rápido que hacer coincidir una cadena. También le permite cambiar libremente el nombre, sin preocuparse por las claves externas almacenadas en otras tablas (la ID permanece igual, por lo que no tiene que hacer nada).

Realmente puede llevar este diseño bastante lejos, y todo es cuestión de averiguar qué quiere almacenar en él.

Por ejemplo, en lugar de tener un solo director por película, algunas películas tienen directores múltiples ... por lo que habría una relación de muchos a muchos entre películas y directores, por lo que necesitaría una tabla con, por ejemplo:

films_directors => **filmid, directorid**

Yendo un paso más allá, a veces los directores también son actores, y viceversa. Entonces, en lugar de tener incluso tablas de director y actor, podría tener una tabla de una sola persona y unirse a esa tabla al usar una tabla de roles. La mesa de roles tendría varias posiciones, por ejemplo, director, productor, estrella, extra, agarre, editor ... y se vería más como:

films => **filmid**, title, otherstuff... people => **personid**, name, .... roles => **roleid**, role name, .... film_people => **filmid, personid, roleid** genre => **genreid**, name, ... film_genre => **genreid, filmid**

También podría tener un campo role_details en la tabla film_people, que podría contener información adicional según el rol (p. Ej., El nombre de la parte que está interpretando el actor).

También estoy mostrando el género como muchas <> muchas relaciones, porque es posible que una película se encuentre en múltiples géneros. Si no quieres esto, entonces en lugar de la tabla film_genre, las películas solo contienen un género.

Una vez configurado esto, es fácil consultar y encontrar todo lo que una persona determinada ha hecho, o todo lo que una persona ha hecho como director, o cualquiera que haya dirigido una película, o todas las personas involucradas en una película específica. Puede seguir y seguir.