Optimizacion De Rendimiento

[juanlito]

Ante todo disculparme por el retraso en responder, me han surgido otras cosas que me tienen muy ocupado y no he podido avanzar con mi problema, ni probar cosas nuevas.

Muchas gracias por tus sugerencias, en cuanto tenga un rato las probare como es debido.

Lo de los indices, deberia de estar indexado pero lo comprobare, como los datos vienen importados de access quizas algunos indices no sean los mejores, vi que se habian creado indices y por eso no les presté la debida atencion.

Con respecto a hacer una sola query con CASE, realmente no se como hacerlo, si hubiera sabido ten por seguro que no tendria un codigo tan complejo, pero viendo que me lo das como opcion( creia que no se podia hacer), me documentare de como podria hacer que mi codigo se redujese a un query.

Sobre el ultimo punto, hice una prueba rapida, y cambiando el 'like' por '=' la verdad es que no note mejora, no calcule exactamente pero estara en el mismo tiempo.

Un saludo y seguire informando de los avances cuando pueda ir probando.

Muchas Gracias

[juanlito]

Buenas Tardes,

consegui hacer todo y que mi aplicacion fuese rapida, pero pensando en el futuro he observado que si uso

Código SQL [-]
 
SELECTcount( PLAT.LINEA) FROM PLAT WHERE ((PLAT.LINEA) = :CALLING) 
   INTO :VECES ;
   if (:VECES = 0)  then
   begin
    EXIT;
    suspend;

El procedimiento cada vez que la tabla vaya creciendo se ira ralentizando porque tendra que finalizar la consulta y a mi con que encuentre un campo me vale.

He estado consultando y he encontrado que con el FIRST podria hacer lo que prentendo, en cuanto encuentre un campo parar la consulta porque ya es distinto de 0 y con eso me sirve, el principal problema es que he puesto el siguiente codigo

Código SQL [-]
  SELECT FIRST 1 ( PLAT.LINEA) FROM PLAT WHERE ((PLAT.LINEA) = :CALLING)
  INTO :VECE;
   if (:VECE IS NULL ) then

Y no me funciona, he probado poniendo order by al final, comparando en el IF en vez de NULL si cadena vacia '' pero no consigo que me funcione como quiero, solo funciona cuando uso el count, pero me gustaria no tener que hacer el select entero y poder quedarme tranquilo de que aunque mis tablas crezcan ( que creceran bastante) no se va a empezar a ralentizar de manera grande.

Pruebo directamente en un view de firebird.

Muchas gracias y si llevo tiempo con el hilo un poco parado es porque siempre procuro solucionar yo los problemas.

Un saludo

[[fjcg02]]

Hola,
PLAT.LINEA es del mismo tipo que VECE ?
VECE será entero, que es el mismo tipo de dato que devuelve COUNT. Por ahí podría darse un conflicto...

Prueba y nos dices

Saludos

[juanlito]

Ya pense en esa opcion,

vece es del mismo tipo que plat.linea VARCHAR(20), por eso no lleva la 's' que llevaba en el codigo del count, para diferenciarlo fue una de las pruebas que hice.

Pero gracias, todas las pruebas son validas, probe con IS NOT NULL, o con cadena vacia '' o con ' ' pero nada siendo un VARCHAR.

[[fjcg02]]

Hola,
he estado echando un vistazo al problema, y creo que lo que te ocurre es que la tabla GUAN tiene muchos registros.

Puedo equivocarme, pero creo que deberías limigtar el nº de registros de la consulta a la tabla GUAN, para que el retardo no se excesivo. Quiero decir, que si estás mirando llamadas, siempre serán las limitadas entre unas horas, minutos, o incluso un día, pero seguramente no se preguntará por todas las llamadas de la tabla.

Respecto al problema de la limitación de registros, en principio la consulta con FIRST es correcta. Has probado a ejecutarla fuera del SP ? Creo que tu idea es correcta respecto a cómo agilizar las consultas, pero a veces es lo que hay. Lo que no sé es si es posible que añadas un campo a tus tablas que se calcule en base al timestamp, para que puedas ponerle un indice y poder cruzar las tablas por él, que sería lo más óptimo. Ten en cuenta que preguntas por un rango de +-2 horas, que es lo que te está rompiendo los tiempos de respuesta.

Un saludo

[juanlito]

Hola

Aunque ha pasado un tiempo voy a intentar explicarlo mejor, porque puse solo una parte del codigo del SP, que era la que queria modificar pero quizas he inducido a error, asi que voy a explicarlo.

El SP consegui que mostrase los datos que queria y que fuese bastante rapido en la respuesta, pero me di cuenta observando en el SQL MANAGER LITE, que podia tener un problema en un futuro, para realizar mis aplicacion introduje en la base de datos los datos solo de un mes, y vi que habia muchas consultas o que se recorrian muchos indices, asi que si ahora solo tengo un mes, cuando tenga datos de un año volvere a tener problemas de Rendimiento.

voy a intentar explicar todo lo que hago, con texto, para que quede claro, si quereis o veis mejor os pongo todo el codigo pero como en realidad el codigo me funciona lo unico que quiero es cambiar una consulta por eso mostre solo esa consulta.

Para cada dato de la tabla que leo que se encuentra entre las fechas introducidas por el usuario,en la primera consulta compruebo si ese dato se encuentra en otra tabla 'GUAN' (en mi pregunta anterior usaba la tabla PLAT, pero realmente es que tengo 2 SP que hacen lo mismo pero inverso, asi que como hoy he estado mirando este pues consulto por este pero el tema es el mismo) este es la consulta que puse porque claro si uso el count, recorro la tabla entera cuando en realidad estoy preguntando solo si ese dato se encuentra en la tabla, realmente solo quiero saber eso no el numero de veces que se repite, si se se encuentra en la tabla pues ya ejecuto el resto del codigo del SP sino pues a siguiente registro.

Pues ese es el tema de este problema, he puesto ese codigo quitando en INTO en un VIEW y funciona correctamente, o me muestra el valor si pertenece o muestra NULL, pero en el SP no funcionan.

Espero haberme explicado con claridad, sino por favor preguntarme y os lo explicare mejor, o pondre el SP completo

Gracias

[[fjcg02]]

Hola,
sería interesante que pusieras todo el SP o la vista. Además, la estructura de las tablas y los índices.

He estado revisando, y ahora no se si utilizas la condición "Like :CALLED"

Si siempre miras por :CALLED+'XXX' o CALLED+'%', te convendría añadir un campo con esa información para evitar utilizar like, que es terriblemente ineficiente. Si no puedes, sería mejor utilizar left(PLAT.DESTINO,LONGITUDCALCULADA) en la condición que el like.

Ya nos contarás.

Saludos