Capacidad de firebird

[ivantech]

entonces para concluir con este tema, marcguillot y casimiro.

si la herramienta y el mecanismo que estamos por implementar (en mi institución) es solo como almacenaje y difusión hasta los niveles superiores de procesamiento y aclarado el punto de las capacidades de firebird con respecto al volumen de almacenaje y rendimiento, también tomando en cuenta que el proceso inicial busca crear la cultura de trabajar con aplicaciones en los niveles inferiores y que ahora en esta etapa no es relevante el echo de la calidad de la información y tomando en consideración que para poder manejar muchas informaciones es necesario que tengamos que trabajar con la indexación adecuada de la Base de Datos. Puedo implementar este modelo sin mayor obstáculo. entonces me gustaría saber si tienen alguna sugerencia o algún sitio donde especifiquen las cosas a tomar en cuenta para realizar consultas e informes con volúmenes de información de mas de 1 millón de registro. ojo no se si tendría que iniciar otro tema o seguimos con este favor de aclararme.

[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.

[Casimiro Notevi]

Aquí tienes un sencillo documento que habla sobre los índices en firebird, está escrito por una de las programadores de firebird.