Optimización de consultas SQL en Visual Foxpro

Posted on octubre 12, 2010

4



Uno de los pasos más traumáticos para un programador de foxpro 2.5 a las últimas versiones, es pensar en utilizar el SQL de forma óptima. Pasar de los bucles tipo SCAN/ENDSCAN DO/ENDDO a una sóla instrucción, y que VFP decida qué índice utilizar, no siempre se hace de la forma más correcta.

Una vez más, la ayuda de fox está bien documentada. A considerar:

– =SYS(3054,12). Permite conocer la optimización de rushome aplicada a la instrucción SQL. Con ella se pueden hacer pruebas y ver si se va por buen camino.

–  Ver si los índices tienen clausulas FOR. Los índices que use SQL deben ser sin clausulas FOR.

– Construcción de la consulta where y el parámetro JOIN / ON. Fox a veces en un poco “tonto”. Hay que dejarle bien claro en el where y en el JOIN los condicionantes de la consulta si es compleja, para que no se desvie internamente generando miles de registros en alguna tambla temporal, para luego devolver 2 o tres 3 simples registros.

– Parámetro FORCE en Select. Puede que FOX piense que su forma de proceder es la ideal para una buena respuesta, pero quien mejor que nosotros para conocer la naturaleza de la tabla.

– Ojo con las subconsultas. Fox va más rápido si la respuesta de la subconsulta tiene los valores esperados al principo de la misma, cuando éstos son comparados con la consulta principal. Hay veces que un LEFT join o una subconsulta pueden hacer lo mismo, pero dependerá del caso, una opción puede ser mejor que la otra. Una vez más, lo mejor es hacer pruebas.

– Obtener sólo aquellos campos de las tablas que vamos a usar. Especialmente importante cuando hay campos memos en las mismas.

– Indicar para cada campo, la tabla de la que procede (Ejemplo: tabla facturas, campo número–> facturas.numero). No se notará en el rendimiento, pero nos evitará problemas en un futro si añadimos más campos a la tabla, y coincidan los nombres de los campos en varias tablas.

Hay que prestar especial cuidado con los parámetros Where y los índices existentes. Una optimización puede ser total o parcial. Para que la consulta sea rápida, hay que luchar para conseguir que la optimización sea total, y con el índice que nosotros queremos, que no siempre es el que FOX decide utilizar.

Si tenemos un índice del tipo EMPRESA+str(NUMFACTURA,10) la consulta Select podría ser:

select * from fichero where empresa=”PR” and numfactura=100 <– optimización parcial, sólo por codigo de empresa

Selet * from fichero where empresa+str(numfactura,10) = “PR”+str(100,10) <– optmización plena.
Siguiendo este mismo principio, se pueden hacer consultas complejas con varias tablas relacionadas en la consulta y conseguir una respuesta rápida, al nivel  de respuesta de un bucle clásico SCAN/ENDSCAN bien optimizado.

Cuando una optimización es parcial o nula, FOX seguramente creará índices internos para mostrarnos la información. Dependiendo del tamaño de los registros requeridos, eso puede ser una penalización importante.

Crear una consulta SQL la puede crear cualquiera. Hacerla optimizada, requiere de cierta práctica y una buena batería de pruebas. Existe infinidad de documentación al respecto en Internet, que recomiendo sea consultada.

Posted in: Foxpro