Si queremos que nuestras aplicaciones “vuelen”, o sea que se ejecuten a gran velocidad podemos usar la técnica que se explica en este artículo. El autor de este blog usa esa técnica desde hace muchos años con gran suceso.

Entendiendo la situación:

El ancho de banda de todas las redes es limitado, en algunos casos puede ser muy grande pero siempre es limitado. Si demasiados datos transitan por la red ésta se vuelve lenta. En general las aplicaciones de bases de datos no saturan la red salvo que haya demasiados usuarios conectados y demasiadas consultas se estén realizando al mismo tiempo.

Sin embargo, la realidad es que muchas veces la misma red que se usa para las aplicaciones de bases de datos también se usa con otros objetivos, por ejemplo para conectarse a Internet. Y en casos así es frecuente que alguien (aunque no debería hacerlo) esté descargando fotografías, canciones, vídeos o películas.

Ante ese panorama no habrá red que aguante, hagamos lo que hagamos para aumentar la velocidad de nuestras consultas siempre serán lentas porque la red estará saturada.

Entonces, el primer y elemental paso es conseguir que la red se use única y exclusivamente para bases de datos y para nada más, por ningún motivo. Si necesitan una red para Internet, que instalen otra, pero la que se usa para bases de datos debe usarse solamente y exclusivamente para bases de datos. Eso es innegociable.

Pero aún teniendo una red exclusiva algunas tareas de los usuarios pueden ser lentas. Veamos:

Una empresa tiene 5.000 clientes, cuando se va a realizar una venta la aplicación muestra en una grilla los nombres de esos clientes. El usuario elige a unos de ellos.

¿Qué sucedió?

Que la consulta del usuario involucró que por la red transiten los datos de esos 5.000 clientes. Si es un solo usuario quien está vendiendo quizás no sea mucho problema pero ¿y si son 10, 40, 80 o más usuarios?

Allí ya es otro tema, porque ya muchos datos están transitando constantemente por la red.

Entonces, lo que necesitamos es una técnica que nos permita obtener los datos de esos 5.000 clientes pero sin usar la red. ¿Es eso posible?

La solución:

Ya hemos visto que si demasiados datos transitan por una red ésta se vuelve lenta, entonces lo que debemos conseguir es que sean muy pocos los datos que transiten por ella para que cuando lo hagan sea a gran velocidad.

Y eso obtendremos si usamos una Base de Datos auxiliar.

En esta Base de Datos auxiliar guardaremos las tablas de lookup y las tablas maestras. ¿Qué son las tablas de lookup? Las que guardan datos que se insertan una sola vez y luego se usan muchas veces, pero nunca se modifican. Por ejemplo: nombres de localidades, nombres de los tipos de documentos, nombres de los tipos de envases, nombres de las unidades de medida, nombres de las marcas de productos, nombres de sucursales, nombres de las monedas extranjeras, nombres de Bancos, nombres de vendedores, nombres de cobradores, nombres de países, etc. En esas tablas se insertan filas pero nunca se las modifica. Bueno, la excepción sería si se escribió mal el nombre, pero solamente eso, nada más se suele cambiar.

Y en las tablas maestras se guardan los datos de clientes, proveedores, productos, etc.

Tanto las filas de las tablas de lookup como las filas de las tablas maestras se usan principalmente para consultas. Y para asegurarnos que en las otras tablas se ingresen datos existentes. Y eso normalmente se realiza a través de restricciones FOREIGN KEY.

Así, si por ejemplo estamos vendiendo en moneda extranjera estaremos seguros que esa moneda extranjera existe, porque su identificador y su nombre lo extraemos de la tabla de MONEDAS. Y en nuestra tabla de VENTAS nunca tendremos una moneda extranjera inexistente porque una restricción FOREIGN KEY lo impedirá.

Entonces, si queremos que nuestras aplicaciones muestren los datos a gran velocidad lo que debemos hacer es usar una Base de Datos local, no una Base de Datos externa.

La idea es la siguiente:

  • Creamos una Base de Datos auxiliar, que se guardará en el disco duro local y a la cual se conectará mediante embedded
  • En nuestra Base de Datos auxiliar guardamos las tablas de lookup y los datos de consulta de las tablas maestras (típicamente identificador, código, nombre, y a veces algunas columnas más) que se encuentran en el Servidor
  • Cuando un usuario quiere consultar una tabla de lookup o una tabla maestra, verificamos que la cantidad de filas de la tabla auxiliar coincida con la cantidad de filas de la tabla en el Servidor. Si no coincide, a la tabla auxiliar le insertamos las filas faltantes
  • Le mostramos al usuario la tabla auxiliar
  • Cuando el usuario eligió una fila de la tabla auxiliar, consultamos (si hace falta) la tabla remota para obtener los otros datos que necesitamos

Ejemplo:

  • Creamos una Base de Datos llamada AUXILIAR.FDB
  • Siempre nos conectaremos a ella usando embedded
  • A esa Base de Datos le agregamos una tabla llamada CLIENTESAUX con las columnas Identificador, Código, Nombre
  • Cuando el usuario necesita consultar los datos de un cliente, verificamos que el último Identificador de la tabla CLIENTESAUX sea igual al último Identificador de la tabla CLIENTES (que es la tabla que tenemos en el Servidor)
  • Si el Identificador de la tabla CLIENTES es mayor que el Identificador de la tabla CLIENTESAUX, le insertamos a la tabla CLIENTESAUX las filas faltantes
  • Le mostramos al usuario el contenido de la tabla CLIENTESAUX
  • Después que el usuario eligió una fila de CLIENTESAUX extraemos de la tabla CLIENTES que se encuentra en el Servidor los demás datos que necesitamos (su teléfono, su e-mail, etc.)

Ventajas:

  • El usuario consulta una tabla que se encuentra en el disco duro de su computadora, eso siempre es mucho más rápido que consultar una tabla que se encuentra en el disco duro de otra computadora
  • La red se usa al mínimo porque si hay 5.000 clientes transitaron por la red los datos de un solo cliente, no los datos de 5.000 clientes

Desventaja:

  • Se complica la programación de nuestra aplicación porque debemos escribir rutinas que se encarguen de actualizar las tablas auxiliares

Importante:

Con esta técnica se consiguen tiempos de respuesta buenísimos pero hay que tener en cuenta que la aplicación debe conectarse a una sola Base de Datos en el Servidor, ya que si primero se conecta a la Base de Datos “A”, luego a la Base de Datos “B”, luego a la Base de Datos “C”, si hay una sola Base de Datos AUXILIAR.FDB habrá que borrar los datos de cada una de sus tablas cada vez que se cambia de Bases de Datos y luego insertar las filas correspondientes. Allí ya se vuelve ineficiente. La solución en ese caso es tener una Base de Datos auxiliar para cada Base de Datos en el Servidor. O sea AUXILIAR_A.FDB, AUXILIAR_B.FDB, AUXILIAR_C.FDB, etc.

Conclusión:

Si creamos una Base de Datos auxiliar a la cual nos conectamos mediante embedded y guardamos en ella las tablas de lookup y las tablas maestras cuando el usuario haga una consulta obtendrá los datos a gran velocidad porque serán leídos desde su disco duro local lo cual siempre es muchísimo más rápido que leerlos desde un disco duro remoto.

La desventaja es que nuestra programación de la aplicación se complicará porque cada vez que el usuario quiera consultar una tabla de lookup o una tabla maestra deberemos verificar que la tabla auxiliar se encuentre actualizada y si no lo está entonces deberemos actualizarla. Siempre la tabla auxiliar deberá estar actualizada antes de mostrarle los datos que pidió.

Artículos relacionados:

¿Es seguro usar Servidor y embedded al mismo tiempo?

El índice del blog Firebird21

El foro del blog Firebird21