[guillotmarc]

Hola Ivan.

En efecto, tienes razón, para trabajar con ese volumen de información es crítico tener los índices adecuados para poder optimizar tus consultas.

La mayor base de datos con la que trabajan mis clientes solo tiene 1Gb (eso dice mucho de la elevada compresión que hace Firebird al guardar los datos), pero almacena la información de 15 tiendas interconectadas y hasta veinte años de su gestión (compras, ventas, etc. ...).

Algunas de sus tablas superan perfectamente el millón de registros (como las líneas de venta) y nunca hemos tenido que implementar ningún mecanismo especial para que funcionen correctamente. Simplemente funciona igual de bien que en una tienda pequeña que solo tenga unos pocos miles de registros. Solo hay que asegurarse de tener los índices adecuados para todas las consultas que se ejecutan a esas tablas.

Lamentablemente no recuerdo ningún artículo ni documento que explique como deben definirse los índices más óptimos en una tabla. Así que no te puedo poner ningún enlace. La verdad es que es bastante intuitivo, pero hay que tener en cuenta que muchas veces necesitarás índices múltiples.

Ejemplo : select * from clientes where Empresa = 1 and Tipo = 4

Aquí lo óptimo no es tener un índice para Empresa y otro para Tipo, puesto que el motor solo va a utilizar uno de los índices. Entonces, supongamos que escoge el índice Tipo (se va a basar en la granularidad del índice, es decir de los índices que pueden acelerar una consulta, va a escoger el que tiene más valores y por lo tanto tiene menos registros asociados a un determinado valor). Supongamos pues que el índice escogido por el motor es el de Tipo, entonces va a tener que recorrer todos los registros del Tipo 4 para evaluar si son de la Empresa 1.

En cambio si definimos un índice múltiple para Tipo + Empresa, entonces el motor puede realizar la consulta de forma inmediata, ya que con ese índice puede detectar inmediatamente los registros del Tipo 4 que también son de la Empresa 1.

NOTA: Con el tiempo los índices se desbalancean (son árboles binario de búsqueda y para su correcto funcionamiento todas las ramas del árbol deben tener aproximadamente el mismo número de nodos, en caso contrario unas consultas serían más rápidas y otras más lentas debidas a que tienen que recorrer un camino más largo en el árbol) por lo que cada mucho tiempo (cada 5 años o así) hacemos una reestructuración de la base de datos (un backup y restore posterior con lo que se rehace la base de datos y los índices se regeneran). Es la única tarea de mantenimiento que hacemos.