Las ventajas de las bases de datos multidimensionales de longitud variable para el diseño de software empresarial

Las bases de datos de longitud variable se caracterizan por almacenar los registros de los archivos ocupando el tamaño que realmente tienen sin reservar espacio para una longitud máxima. Así por ejemplo, para gestionar o almacenar una ficha de artículo o producto, puede que la referencia A tenga asociada un tamaño de 150 caracteres (suma de longitudes de sus campos) y la referencia B un tamaño de 2,000, el archivo físico en disco ocupará aproximadamente 2,150 caracteres o bytes.

En las tablas tradicionales de la mayoría de bases de datos bidimensionales que se usan para diseño de soluciones de gestión, sería preciso hacer una reserva de espacio por registro (pongamos 2,500 bytes como máximo por registro), y en éste caso para almacenar A y B necesitaríamos 5,000 bytes.

Cuando hablamos de pocos registros, esto apenas tiene importancia, pero para aplicaciones reales, el no usar longitud variable dispara la ocupación de las tablas.

Me dirán: Hoy en día, con el tamaño de los discos duros (Terabytes) ¿Qué más da el tamaño de los registros?.

Respuesta: Minimizar el tamaño de las bases de datos para crear software de gestión, no es que sea importante sino imprescindible para diseñar buenas soluciones.

No optimizar dicho tamaño, tiene implicaciones negativas futuras:
Lentitud en los procesos de la aplicación
No posibilidad de acceso a históricos de ejercicios anteriores de forma ágil
Incremento exponencial en costes de hardware y anchos de banda
Dificultad y complejidad en las tareas de copia y mantenimiento
En definitiva, muchos mayores costes en general

Por otra parte, la longitud variable permite diseñar estructuras multi-dimensionales para almacenar los datos, lo cual confiere grandes ventajas:
Rapidez y simplicidad de diseño
Es más fácil la solución de tareas complejas de gestión
Más rapidez en la ejecución y el mantenimiento
Más sencillez y agilidad para reformas o ampliaciones de aplicaciones.

Para entender estas implicaciones, veamos un ejemplo, una simple factura, en ella hemos de diferenciar:
Datos de cabecera
Líneas de productos
Posibilidad de desglose de unidades totales por tallas, colores u otro concepto (en cada línea)
Observaciones
Cuadro de desglose de impuestos (bases imponibles e IVA)
Cuadro de vencimientos o cobros previstos (fecha e importes)
Cuadro de cobros realizados (nº cobro, fecha e importe)
Cuadro con desglose para contabilidad (cuentas e importes)
Posible cuadro de notas de entrega o albaranes asociados

El modelo tradicional: tablas bi-dimensionales relacionadas

Para resolver su almacenamiento de forma tradicional, como se hace actualmente en la mayoría de las soluciones de gestión, necesitamos definir 9 zonas de almacenamientoo tablas relacionadas y en cada tabla es necesario construir de forma artificial índices para relacionar con el documento principal (cabecera). La tabla asociada a las líneas de productos, debe tener un índice que sea el número de factura y se ha de repetir en cada registro de la tabla. Para almacenar el desglose de unidades por tallas, debemos diseñar una tabla mucho más compleja con un índice que nos permita identificar: nº de factura, nº de línea, producto, talla y unidades. Gran complejidad a la hora de borrar, insertar o querer ordenar dichas tablas.

En definitiva, no es que este modelo sea totalmente ineficaz, es que además, para almacenar una simple factura estamos creando una estructura artificial que implica almacenar de forma repetida por factura gran cantidad de datos para establecer las relaciones. Si además se da el caso de bases de datos de longitud fija, el artificio así creado funciona, pero los recursos utilizados son ingentes.

¿Qué implicaciones tiene éste modelo tan complejo para mantenimiento, modificación o ampliación de las aplicaciones?. Respuesta: tiempos y costes disparatados debido a la complejidad de diseño.

¿Qué implicaciones tiene para la ejecución de las aplicaciones?, Respuesta: lentitud de proceso, ya que para trabajar con una simple factura está implícita la gestión de 9 tablas.

El modelo de longitud variable

En el modelo de base de datos relacional de longitud variable, sólo es necesario utilizar una única zona de almacenamiento de datos, tabla o archivo. Todos los elementos antes indicados no son más que campos que pueden ser de varias dimensiones.

Las líneas de productos, se almacenan en un campo bi-dimensional de longitud variable (dicho campo puede tener una línea o miles de líneas), el desglose de unidades en cada línea de éste campo, se hace simplemente creando un sub-campo que a su vez tiene dos dimensiones para que sea posible almacenar unidades y tallas en varias filas.

Conclusiones

Si el mundo en que vivimos, aparentemente tiene una estructura tetra-dimensional,¿Por qué resolver los problemas reales de forma artificial usando complejas estructuras de tablas bi-dimensionales relacionadas?.

Si es posible, ¿Por qué no usar una estructura multidimensional relacionada?

gsBase aporta una base de datos relacional de longitud variable con estructura multi-dimensional.