Re: normalizacion

En cuanto a la relativa "importancia" yo creo que la normalizacion son
lineamientos de diseño que se siguen si es útil y si no no, no las
tomaria como "reglas".

En el caso particular de los documentos, hay un tema subyacente que
es el manejo en el tiempo de los datos (algo que, para sistemas
transaccionales normalmente se simplifica con soluciones de compromiso
como esta, de "congelar" los datos solo para los casos que lo
requieran y pisar las entidades base cada vez que hay una
modificacion)

La factura hace referencia al dato en un momento del tiempo, no es
estrictamente el mismo "dato" de dos años despues.
En otros entornos, por ejemplo en DataWarehouse, donde es relevante la
evolucion en el tiempo de los datos, ya que no se piensa en el dia a
dia de sistemas transaccionales, sino en analisis mas globales y a mas
largo plazo, hay un analisis mucho mas detallado de distintas
soluciones a este problema de los cambios graduales de las entidades
(en DW "dimensiones", segun la necesidad y segun el tipo de
fluctuaciones en el tiempo de la dimension, se ve cuando simplemente
pisar el dato anterior, cuando generar uno nuevo desvinculado, cuando
ir generando "fotos" y guardando el vinculo para relacionarlas, etc)

En realidad, la regla de negocio no esta "en contra de la
normalizacion" sino que la normalizacion que usamos comunmente es una
version simplificada de la que en teoria se deberia usar.

En cuanto al segundo punto, la performance, puede justificar una
desnormalizacion (y normalmente es asi), cuando el volumen de datos es
demasiado grande para estar recalculando los valores en cada consulta,
pero en estos casos, lo fundamental es que se hace de un modo
controlado y son datos "caché", nunca se escriben, están solo a modo
de optimizacion y normalmente se manejan con triggers o soluciones
centralizadas y no librados a la memoria del programador de turno.

2008/7/25 José Fermín Francisco Ferreras <josefermin54(at)hotmail(dot)com>:
> Gracias a todos por responder.
> Según lo q he leido, hay dos posibles respuestas para este asunto:
>
> 1. La q dijo alvaro herrera, d q los programadores no tienen idea d como
> diseñar una base d datos.
> 2. La q dijo Sam y otros acerca d esto:
>
> 'Esto puede ser debido a que la factura, boleta son documentos
> contables, y se requiere saber conque nombre fue impreso, si fue
> impreso con un nombre equivocado, esta factura se anula , se cambia la
> información en el maestro, mas no en la factura anulada.'
>
> 'Una explicacion posible es que cuando se guarda registro de documentos
> impresos con valor legal, los datos se deben guardar tal cual al
> momento de la impresion, por esto es que a veces esta el requerimiento
> de replicarlos en cada registro, si posteriormente las tablas de
> entidades cambian, cada documento se mantiene tal cual cuando fue
> generado.'
>
>
> - Entonces, esto quiere decir decir q las reglas d los negocios es mas
> importante q las reglas d normalizacion??
>
> - Escuche a un programador decir q es mejor redundar porque así el
> procesador trabaja menos forzado y por consiguiente sacrificar espacio en
> disco le resulta mucho mas comodo al sistema. Osea mayor procesamiento, pero
> con carga extra en el disco.
>