Organización DB

[lvfp]

Hola:

Tengo que preparar una Db que tiene no menos de 40 campos de datos y alguno de ellos podría tener más de un valor, por ejemplo, una película con:

Director
Productor
Guionista
Actor principal
.
.
.
.
.

Alguno de ellos puede tener dos datos o más, puede haber más de un productor o más de un director...

No tengo muy claro como organizar las tablas. Alguien me puede "iluminar"

Gracias.

[Ribon]

Bueno alumno, déjame decirte que poco se puede hacer si no pones más detalles sobre que debe tener tu base de datos, supongo que es de películas, pero el caso completo como sería.

De todas formas lo que tu necesitas saber es sobre diseño de base de datos. pero con lo que dijiste nada más puedo ayudarte xD!

saludos.

[nyahikari]

Como te dijeron anteriormente se necesita mas informacion de tu bd pero con lo poco que has dicho puedo darte un pequeño alcance

Si se tiene dos tablas

TB_Pelicula

id (primary key)
nombre
añoEstreno
.
.
.

TB_DIRECTOR

id (primary key)
nombre
apellido
nacionalidad

Considerando ademas, que un director puede dirigir muchas peliculas y una pelicula puede ser dirigida por muchos directores entonces es una relacion de muchos a muchos y eso se rompe con una tabla adicional

TB_PELICULAS_X_DIRECTOR

id(primary key)
idDirector
idPelicula

y la misma relacion cumpliria con actores, guionistas, ...

[lvfp]

Hola:

Gracias a los dos por contestar. MI duda es por la gran cantidad de campos que tendría si hago una tabla única y la gran cantidad de tablas si hago una para cada categoría.

Por lo que entiendo me recomiendas la segunda opción, una tabla para los datos propios de cada película y otras para campos como actores, guionistas... relacionados con cada película.

S2

[Ribon]

cuando hagas tus tablas ponlas acá y te ayudamnos a normalizarlas :)

saludos.

[lvfp]

Serían 70 tablas... y además de visualizar los datos tendría un panel de administrador para introducirlos. Y a lo mejor digo una burrada, pero tendría 70 inserts (alguno con más de un dato) para meter los datos en cada tabla. Y al recuperar datos 70 consultas...

¿Eso sería así o se me está fundiendo la masa cerebral? Como veis mysql yo poco, me manejo en acces, pero puede que eso me confunda (como la noche) :D

[Ribon]

Tienes una herraminetas como MySQL Workbench para mostrar el modelo de datos resultante?

saludos.

[gnzsoloyo]

Iniciado por lvfp

Serían 70 tablas... y además de visualizar los datos tendría un panel de administrador para introducirlos. Y a lo mejor digo una burrada, pero tendría 70 inserts (alguno con más de un dato) para meter los datos en cada tabla. Y al recuperar datos 70 consultas...

¿Eso sería así o se me está fundiendo la masa cerebral? Como veis mysql yo poco, me manejo en acces, pero puede que eso me confunda (como la noche) :D

¿No ería mejor que empieces por describir en forma general qué datos piensas almacenar, qué es lo que se consultará, qué cosas se podran agregar... Es decir, describe un poco el sistema y entonces podremos ver hacia donde hay que diseñar.
Por otro lado, ¿en qué te basas para afirmar que necesitas 70 tablas? ¿Cómo estás dividiendo conceptualmente los datos?
Te anticipo un TIP: No se usa una tabla para cada película. Eso es insensato, porque terminarás con infinitas tablas.
Se usa una tabla para películas, una para directores, otra para actores, una para relacionar las peliculas con los directores, otra para relacionar las peliculas con los acores, etc.. El esquema se desprende de la normalización (Ver Formas Normales) que se aplique a la base.

[lvfp]

Por eso, tengo 70 campos para cada película, casi todos podrían llevar varios valores. Mi idea era hacer una tabla general, con los datos que no puedan ser más que 1 después una para cada dato que pueda ser múltiple. Para el administrador páginas para introducir los datos por bloques para evitarme muchas llamadas a la db y para el usuario que vea todos los datos seguidos, eso me obliga a muchas llamadas a las tablas, no sé cuantas son ya demasiadas.

Gracias.

[gnzsoloyo]

Iniciado por lvfp

Por eso, tengo 70 campos para cada película, casi todos podrían llevar varios valores. Mi idea era hacer una tabla general, con los datos que no puedan ser más que 1 después una para cada dato que pueda ser múltiple. Para el administrador páginas para introducir los datos por bloques para evitarme muchas llamadas a la db y para el usuario que vea todos los datos seguidos, eso me obliga a muchas llamadas a las tablas, no sé cuantas son ya demasiadas.

Gracias.

Disculpa, pero no se entiende nada de lo que dices.
Como te dije:
¿No sería mejor que empieces por describir en forma general qué datos piensas almacenar, qué es lo que se consultará, qué cosas se podrán agregar... Es decir, describe un poco el sistema y entonces podremos ver hacia donde hay que diseñar.
Por otro lado, ¿en qué te basas para afirmar que necesitas 70 tablas? ¿Cómo estás dividiendo conceptualmente los datos?

tengo 70 campos para cada película, casi todos podrían llevar varios valores

Te voy a dar otro tip: No existen los campos multivaluados en las base de datos. Son una violación flagrante al paradigma relacional y generan enormes problemas con las consultas, con la integridad referencial, y con la consistencia de datos.
Por otro lado, 70 campos para describir una película pueden estar bien o terriblemente mal, de acuerdo a qué representan esos campos. En general, tales cantidades de campos sugieren que no se ha normalizado es base de datos.

Hasta lo que se comprende lo que intentas "explicar", estás yendo por mal camino en varias cosas.


Empieza por el principio, como te digo: Descríbenos el sistema de acuerdo a cómo debería funcionar. Explica las reglas de negocio (si no entiendes la expresión, busca en Wikipedia), y veremos cómo es el modelo que puede implementarse.

[lvfp]

A ver... perdón por la explicación, pero creía que más o menos se pillaba sin dar datos tan minuciosos. Lo explico lo mejor que sé:

1-La web mostrará los datos de unas series de TV, con unos 70 enunciados de datos, título, temporada, año de emisión, director, productor, actores.....

2-Cada dato de la serie podría llevar más de un valor, por ejemplo el apartado "actores" podría llegar a 15 ó 20 nombres.

(Cuando hablaba de los campos con más de un dato me refería a que no es campo= 1 nombre, ya sé que no es correcto, pero pensaba que se entendía, disculpas.)

3-Habrá una página de administración donde cubrir los datos de cada serie.

Y no tiene nada más, mi pregunta se basa en que la estructura que yo creo que tengo que hacer me crea muchas llamadas a la db por lo que pensaba hacer una tabla con los datos que son únicos, titulo, año emisión, temporada... y otras tablas para los datos que son multiples: actores, guionistas, directores, peluquería, músicos,... etc. para minimizar en lo posible esas llamadas.

No sé si ahora está algo más claro.

Mi experiencia con mysql + php se reduce a llamadas a db bastante simples, pero ahora me encuentro con esto.

Gracias.

[GatorV]

Lee sobre relaciones 1:n, o m:n, no es que tengas múltiples tablas, simplemente tienes otra tabla para los actores, y luego los referencias, ya que los actores pueden estar en 1 o más series, entonces ocupas una relación m:n (o relación de muchos a muchos) no es necesario tener mil tablas, una relación sencilla puede bastar.

[lvfp]

Ok, pero eso o tengo que hacer con otros 50 ya que la mayoría de ellos pueden tener 1 o más datos, puede haber más de un guionista, más de un músico, más de un peluquero.... por lo que ¿deberé entonces usar un join para cada dato? Perdón si digo alguna bobada.