En el foro xBase de Olivares 2000 se ha formado una interesante discusión sobre si normalizar o no las bases de datos.
Está claro que la normalización puede llegar a casos extremos de hacer que el tratamiento de la información se complique excesivamente o bien que termine por reducir el rendimiento del sistema al tener que efectuarse muchas búsquedas en tablas. Por lo tanto hay que llegar a un nivel óptimo de normalización que impida la redundancia de datos innecesaria y la perdida de rendimiento del sistema.
A la hora de diseñar la base de datos hay que definir claramente que datos serán suceptibles de variación en el tiempo, cuales son específicos de un proceso y cuales van a ser estáticos.
Por ejemplo:
en un sistema de gestión, los datos de los clientes, la descripción del artículo, la familia a la que pertenece, los datos de un proveedor, los de un agente, etc., son datos que no van a sufrir variaciones (aunque sabemos que la gente puede cambiar de domicilio);
en ese mismo sistema de gestión tendremos datos que van a poder variar en el tiempo, los datos referentes a precios, margenes y demás sufrirán variaciones, y atañen a las lineas de detalle correspondientes;
y no olvidemos los datos específicos de un proceso, el total de una factura es un dato propio de la factura, por lo que debera incluirse entre los datos de cabecera.
¿Entonces que hay que normalizar? Habra que normalizar todos los datos que consideremos fijos, ¿y si un cliente cambia de dirección? Partimos de la base que ya se ha emitido la factura, que por sí es un documento mercantil que no se puede modificar, ¿debemos guardar todos los datos relativos al domicilio del cliente en el registro de facturas? Eso dependerá de las leyes de cada páis, por que hasta donde yo se, los clientes están identificados fiscalmente por su CIF (o NIF), y si hoy se cambia de domicilio y me pide un duplicado de la factura de la semana pasada, pues o saco fotocopia de la copia que estoy obligado a guardar (y le planto el sello de "duplicado") o se la emito con la nueva dirección y no pasa nada por que fiscalmente ese sujeto está identificado por su CIF.
Por otra parte, y dado ese caso, también podemos "rizar el rizo" y hacer una tabla que guarde las distintas direcciones que pueda tener el cliente y facturarle a la que corresponda ¿o no? (Esto es una aberración, pero no imposible).
Otra solución pasaría por guardar imágen del documento impreso capturando el preview, por ejemplo, para después sólo "reimprimir" ese documento.
En la discusión del foro también se habla de lentitud a la hora de meter los datos de las lineas de la factura en un browse o grid y que para ganar velocidad lo mejor es guardarse el nombre del artículo en la tabla de lineas de facturas.... Aquí tengo que protestar enegicamente, eso si que no se debe hacer (como poder, cada cual puede hacer lo que quiera), si el proceso es lento es por que el browse no trabaja correctamente, el programador no ha diseñado bien las búsquedas o la aplicación hace aguas por alguna parte: ¿carga excesiva de datos inecesarios? ¿indices mal diseñados? ¿código mal elaborado?; muchas veces creamos funciones para buscar cosas y queremos que sean tan genéricas que terminan siendo un sinfin de IF, uno detras de otro, que hacen que buscar la descripción de un artículo sea casi imposible.
Pues hasta donde yo se, SI que es necesario almacenar junto con cada factura los datos fiscales, incluida la dirección, que estuvieran vigentes en el momento de emitir la factura, porque en cualquier instante se ha de poder reimprimir la factura tal como fue emitida.
Comentado por Jose Alberto a Martes, 28 de Junio de 2005Jose Alberto,
No ando muy seguro de lo que voy a decir, pero reimprimir una factura ya emitida no es legal a no ser que se identifique como duplicado de la original por el mismo sistema.
Por otro lado, tal como tenemos la legislación hoy por hoy, el emisor debe guardar copia de las facturas emitidas para contingencias de este tipo.
Además, lo que siempre se ha hecho en sistemas de información es generar una tabla histórica con todos los datos relativos a las facturas emitidas en el periodo correspondiente (sin normalizar) y eliminarlas de las tablas de trabajo (para agilizar el sistema). Por supuesto hay que crear todos los procesos necesarios para poder obtener información de los datos almacenados en las tablas históricas.
Otro tema es que por comodidad y por que los sistemas son muy potentes hoy en día, la práctica de limpiar las tablas de trabajo y almacenar la información en históricos se está perdiendo. Incomodidad por que es un latazo generar procesos para interpretar la información almacenada en las tablas históricas y que ya han sido realizados para las tablas de trabajo.
Un saludo
Comentado por Jose A. Suárez a Martes, 28 de Junio de 2005Yo sigo aplicando el sistema de cierres mensuales/trimestrales/anuales en mis aplicaciones y sólo se puede obtener información estadística después de haberlos efectuado.
Funcionan así:
Cierre mensual: se puede hacer todas las veces que se quiera, vuelca toda la información de las tablas de trabajo al histórico (sin normalizar aunque se guardan tambien los códigos para poder agrupar datos), vuelca información en contabilidad y limpia las tablas de trabajo. Al limpiar las tablas de trabajo no se duplica información en el proximo cierre. Hay posibilidad de recuperar información y editarla.
Cierre trimestral: Se hace una vez al trimestre y se programa de forma automática en el servidor para que lo haga por la noche. También genera los informes que indique el cliente y los guarda para poderlos imprimir cuando se deseen. Marca todos los datos del trimestre como cerrados y es ireversible.
Cierre anual: Se hace a final del ejercicio, se vuelca toda la información del histórico mensual (contiene todos los meses del año) en un acumulado de años para posteriormente poder sacar estadísticas por años. Se limpian las tablas del historico mensual. Es un proceso irrversible.
Por otra parte, todo documento mercantil que se genera queda guardado para poder ser reimpreso sin necesidad de tocar las bases de datos (emision de facturas, recibos, etc.)
Comentado por Tony Sevilla a Martes, 28 de Junio de 2005Tony,
Las tablas históricas desnormalizadas, aunque se almacenan con el resto de tablas de la base de datos, no forman parte de la misma al no tener ningún tipo de interrelación con el resto de las tablas.
Deduzco de lo que cuentas que tus bases de datos se mantienen normalizadas mientras recogen información de los procesos diarios, es decir, que la aplicación hace uso de una base de datos normalizada y que se desnormaliza en los cierres para mantener la información en el mismo estado que se generó.
Un saludo,
Comentado por Jose A. Suárez a Martes, 28 de Junio de 2005Exactamente. La aplicación usa datos normalizados y no he notado nunca disminución del rendimiento.
Las tablas históricas se relacioan con algunas de la base de datos, como la de imágenes y la de familias de artículos, que a mi modo de ver son inalterables.
Comentado por Tony Sevilla a Martes, 28 de Junio de 2005