[Php-avanzado] Hasta que punto conviene Normalizar una DB

Mar Abr 26 14:25:40 ART 2011

Ufff... es muy difícil interpretar una normalización desconociendo el
enunciado del problema...
Que te aparezcan tantas tablas es normal, porque resulta que clasificar
películas o libros o música es algo intrínsicamente complejo, porque
todas las partes tienen con otras relaciones muchos-a-muchos (y una
relación n-a-n requiere una tabla para ser implementada).

Tus tablas _has_ apestan: no tenés una forma unívoca de acceder a un
registro, o las claves son múltiples: en toda la normalización estás
usando como clave primaria una clave artificial (el ID autoincremental)
pero por algún motivo completamente extraño en las tablas de las
relaciones no: vas a volver loco (y pesado) al sistema para manejar la
integridad referencial!

Si te genera dudas que normalizar sea lo correcto, tenemos dos
escenarios: 
1) dudás de que la normalización funcione: en ese caso, leete las bases
teóricas y matemáticas de la normalización, empezando por los papers de
Codd en los 70' hasta ahora. Si no te convence, podés formular tu propia
estrategia de funcionamiento, como están haciendo justo hace unos 3 años
la gente de No-SQL.
2) dudás de que esté bien normalizado: estás en el lugar correcto para
que, entre todos, podamos chequear tu normalización (pero sin el
enunciado del problema ni la lista completa de datos a guardar, no es
tan fácil).

Tener más de 100 tablas está buenísimo: suponete que tenés que guardar
10 millones de registros. Teniendo 100 tablas, deberías tener tablas
promediando) de solo 100.000 registros cada una, lo cual significa que
todo va a ser muy rápido.
Si en cambio tuvieras solo 20 tablas, tendrías tablas de medio millón de
registros, lo que es sin dudas más pesado de usar y acceder.

La pregunta no es "cuántas tablas voy a tener?", sino, "cuantos
registros necesito proyectar a la vez para hacer las relaciones
necesarias para mostrar los datos?"

No trabajamos con tablas: trabajamos con proyecciones.

De hecho una forma de alivianar el sistema sería creando una tabla de
comentarios para cada tipo de comentarios: e decir, se crean más tablas
para que todo sea más liviano.

	Saludos!

PD: qué es una "notificación"? por qué se guardan en vez de por ejemplo
enviarse por email? Si se guardan: qué sentido tiene guardarlas para
siempre y no las tirás después de que el usuario es notificado?

El mar, 26-04-2011 a las 11:30 -0300, Rama Gonzalo escribió:
> Paso una captura de la normalización que aplique para la relaciones 
> entre la tablas comentarios y notificaciones, con el resto de la tablas. 
> Esta en la parte inferior de la imagen. El resto aun no lo normalice.
> La verdad que me generar dudas de que esto sea lo correcto... voy a 
> tener más de 100 tablas cuando termine el diseño.., si es que la 
> normalización esta bien realizada. Aun me queda agregar varias tablas 
> que cumplen funciones similares a las tablas comentarios y notificaciones..
> 
> http://soynn.com/diagrama.db.png
> 
> gracias!.
> 
> > Hola Gonzalo,
> >
> > El lun, 25-04-2011 a las 13:32 -0300, Rama Gonzalo escribió:
> >> Sigo normalizando.. o desnormalizando ?..
> > 	normalizá, que a la larga, siempre es mejor.
> >
> >> Tengo un table "video" otra "serie" y otra  "temporada" .
> >> Un "video","serie" o "temporada" tienen uno o varios "títulos" (según el
> >> idioma) y una o varias "descripciones" (según el idioma), una "serie" es
> >> una colección de "temporadas" y una "temporada" es una coleccción de videos.
> > 	Bueno... una "colección" es otro concepto, y por el problema de
> > impedancia de paradigmas Relacional-OOP, no se pueden (literalmente!)
> > mezclar las cosas.
> >
> >> hice esto:
> >> --tabla video--
> >> id
> >> pais_id
> >> idioma_id
> >> titulo_id (primaria)
> >> descripcion_id (primaria)
> >> serie_id
> >> temporada_id (no es primaria)
> > 	No entiendo: si "tienen uno o varios "títulos" (según el  idioma)" no
> > tiene sentido que acá esté el idioma... ni el título.
> > 	Idem para los demás...
> >
> >> ---serie---
> >> id
> >> pais_id
> >> idioma_id
> >> titulo_id (primaria)
> >> descripcion_id (primaria)
> >>
> >> ---temporada-
> >> id
> >> titulo_id (primaria)
> >> descripcion_id (primaria)
> >> serie_id
> >>
> >> ---titulo----
> >> id (no es clave primaria)  se repite tantas veces como títulos tenga un
> >> mismo video
> >> texto
> >> idioma_id
> > 	Horrible! Hacé que, además del id para la relación, tenga un id único
> > primario. Si no podés acceder unívocamente a un registro, estás frito!
> > 	Idem para la siguiente.
> >
> >> ---descripcion ---
> >> id (no es clave primaria) se repite tantas veces como descripciones
> >> tenga un video
> >> texto
> >> idioma_id
> >> oiginal (buleano que indica si es el titulo orignal del video)
> >>
> >> De esta forma.., a partir de una serie acceso a todos los videos de y
> >> temporadas de la misma e inversamiente, desde un video puedo acceder a
> >> toda la serie y temporadas de la serie, de la que es parte el video.
> > 	Esta característica se dará siempre que tengas normalizados los datos,
> > y puede no darse si no está normalizado.
> >
> >>   No me gusta el diseño, pero "creo" que evitar varias tablas y por ende
> >> muchos JOIN.. y gano algo rendimiento (suponiendo que es un DB con alto
> >> tráfico).
> > 	No es cierto: las DB están preparadas para responder rápidamente sobre
> > una estructura normalizada. Tiene más penalización de rendimiento que no
> > normalices.
> >
> >> -----------------Otra podría ser:
> >>
> >> ---video---
> >> id
> >> pais_id
> >> idioma_id
> >> titulo_original_id (primaria)
> >>
> >> --- serie
> >> id
> >> pais_id
> >> idioma_id
> >> titulo_original_id (primaria)
> >>
> >> ---temporada
> >> id (primaria)
> >> serie_id
> >>
> >> -----titulo
> >> id (primaria)
> >> text
> >> idioma_id
> >>
> >> ----descripcion
> >> id (primaria)
> >> text
> >> idioma_id
> >>
> >>
> >> ---rel_video_titulo
> >> video_id
> >> titulo_id
> >> --rel_video_descripcion
> >> video_id
> >> descripcion_id
> >>
> >> ---rel_serie_titulo (similar video)
> >> ---rel_serie_decripción (similar video)
> >> ---rel_tempora_titulo  (similar video)
> >> ---rel_temporada_descripcon (similar video)
> >>
> >> De esta forma tendría todo más normalizado, con unas  6 tablas más. Pero
> >> ¿bajaría mucho el rendimiento ?
> > 	No.
> > 	El rendimiento será bueno o no dependiendo de si tenés buenos índices o
> > no, y casi de nada más.
> >
> >> Se podrían "quizá" fusionar las tablas titulo y descripción ,
> >> y reducir la cantidad de relaciones.
> >
> > 	Por el problema que describís, tiene sentido que el título y la
> > descripción para un idioma estén en una sola tabla, porque la
> > normalización dice que ambos dependen de la misma clave primaria.
> >
> > 	Dos cosas: la cantidad de relaciones es irrelevante.
> > 	La normalización no es opinable: se aplica el método y nada más. Vos
> > estás planteando las cosas al revés... deberías primero normalizar en
> > 3FN, y sobre el conjunto de tablas y campos que surjan, ver si podés y
> > vale la pena "ahorrarse" algo.
> >
> >
> >> Muchas gracias! nuevamente.
> > 	por nada...
> >
> >
> > PD: y la tabla de usuarios? ;-)
> >
> _______________________________________________
> Php-avanzado mailing list
> Php-avanzado en pato2.fi.mdp.edu.ar
> http://www3.fi.mdp.edu.ar/cgi-bin/mailman/listinfo/php-avanzado
> 

-- 
Leonardo Tadei
leonardot en pegasusnet.com.ar
Firma pública: http://www.pegasusnet.com.ar/LeonardoTadei-public.key