Degradacion de servicio - Firebird

[Casimiro Noteví]

Ha cambiado la dirección, ahora lo encontrarás aquí.

[IVAND]

Gracias por tu respuesta amigo

Estoy bajando el programa que me recomendaste , seria interesante si existiese una guia de la manera de colocar las tablas , indices para obtener un mejor rendimiento


Gracias de nuevo

[Casimiro Noteví]

Es cuestión de hacer pruebas, muchas pruebas, hasta encontrar la forma más óptima.
Cualquier consulta en un programa, que luego va a estar funcionando en una empresa, debe depurarse hasta encontrar la opción más efectiva, haciendo pruebas con muchos datos, lo más reales posibles.

[Ruitoquefly]

Te comento que yo tambien tuve este problema, tenia una tabla de 2500000 de registros y las consultas se demoraban minutos, investigando, encontre un ariculo que hablaba de ello , pero desafortunadamente no en acuerdo donde lo lei pero te puedo resumir que el problema consistia en la definicion de los indices,
porque si en las condiciones del where no existe el indice exacto que permita su busqueda, lo que hace el motor es generar un indice temporal, y es alli donde esta la demora.
Ejemplo
select * from tabla where fecha=mfecha and numero=mNumero and estado='c'

debes tener un indice para la fecha otro para el numero y otro para el estado

y como te comentan es cuestion de probar y probar

[IVAND]

Gracias amigo por tu respuesta

Les comento que me decidi por hacer un SP que de alguna manera se supero la velocidad pero no en mayor cosa , seguire probando pero tambien lei que si uno crea demasiados indices el Insert tambien se hace lento

El problema parece tambien en la vista :-) (salvo que este equivocado las vistas son una solucion y a la vez un problema , Tambien cuando se realizan agrupaciones por nombres (caracteres) y algunas cosas mas

Pero probare con indices aunque las tablas que tengo y las uniones que hago tienen indices (algunas son indices primarios )

[gabrielkc]

Alguna vez tube un problema parecido en un select con varios SUM, cuando unia las primeras dos tablas con una tercera se incrementaba escandalosamente el tiempo de la consulta. Haciendo pruebas me di cuenta que la tercera tabla generaba tuplas con campos en null, y al cuando firebird trata de sumar ese Null al resultado del SUM al no poder pierde algo de tiempo (supongo que cachando la excepcion) y luego se sigue con el siguiente registro, hacer esto en miles de registros le lleva una cantidad extraordinaria de tiempo.

No se si sea tu caso (porque yo usaba LEFT JOIN) pero si no para ti (hace 2 años de tu pregunta :P) espero a alguien le sirva