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

[Leonardo Tadei - Pegasus Tech Supply]

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? ;-)

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