¿Normalizar o no normalizar?
Tuesday, June 28th, 2005En 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.


