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

Mar Abr 26 19:48:48 ART 2011

1º) Gracias.
 Leo mis tablas tablas _has_ tienen clave multiple,
¿para que necesito un campo ID?
¿qué beneficios me trae?
¿porque se vuelve pesado la no tener un ID simple?

--
2º) Si planteo como modelo esto: 
--comment---
id:        (id único )
text:      (contenido )
comment_id:(id , del "posible" comentario. relacionado a este comentario)
model_name:(nombre de la sección que se comentario, ej: noticie, gallery, image, tec)
model_id:  (id se la sección comentada, ej:noticie_id , gallery_id, image_id, etc)

¿que tanto apesta? :)

3º)  ¿cómo se ven estas relaciones? --> http://soynn.com/diagrama.db.png 
  Partiendo por ejemplo de que se realiza una búsqueda en la tabla --title-description-- y se pretende listar los vídeos encontrados y de pertenecer a una serie, listar el árbol de témporas con sus capítulos. 

Saludos.. 
PD.: Tengo toda la descripción del proyecto y los requerimientos, son  largos... Si quieren los llevo el sábado.

--- El mar 26-abr-11, Leonardo Tadei - Pegasus Tech Supply <leonardot en pegasusnet.com.ar> escribió:

> De: Leonardo Tadei - Pegasus Tech Supply <leonardot en pegasusnet.com.ar>
> Asunto: Re: [Php-avanzado] Hasta que punto conviene Normalizar una DB
> Para: "Lista del curso de PHP Avanzado" <php-avanzado en pato2.fi.mdp.edu.ar>
> Fecha: martes, 26 de abril de 2011, 14:25
> 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
> 
> _______________________________________________
> Php-avanzado mailing list
> Php-avanzado en pato2.fi.mdp.edu.ar
> http://www3.fi.mdp.edu.ar/cgi-bin/mailman/listinfo/php-avanzado
> 