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 <[EMAIL PROTECTED]>: > 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. > -- TIP 1: para suscribirte y desuscribirte, visita http://archives.postgresql.org/pgsql-es-ayuda
