FTP | CCD | Buscar | Trucos | Trabajo | Foros |
|
Registrarse | FAQ | Miembros | Calendario | Guía de estilo | Temas de Hoy |
|
Herramientas | Buscar en Tema | Desplegado |
#1
|
|||
|
|||
Consulta Selectiva sobre Store Procedure
Que tal amigos del Foro, tengo este pequeño problema
Tengo un SP en el cual genero una consulta algo compleja, dentro de la cual uno 2 tablas de unos 1700 registros cada una con un INNER JOIN, hasta aqui todo bien, resulta que 2 campos que necesito en la consulta los extraigo de otras 2 tablas tambien master/detail las cuales tienen aproximadamente (170,000, y 370,000) respectivamente, pues para no cansarlos, hago esto SELECT * FROM INV_REP_INVENTARIO_FECHA('NOW') y la ejecuta en unos 200ms pero si hago esto SELECT EXISTENCIA FROM INV_REP_INVENTARIO_FECHA('NOW') WHERE PRODUCTO = '010001' tarda como 35000ms que puede estar pasando, ya revise los indices con el PLANalyzer y nada que no se que puedo hacer Gracias. |
#2
|
||||
|
||||
Hola.
Añade un parámetro al procedimiento almacenado. De esta forma la consulta se optimizará dentro del procedimiento almacenado. Como probablemente ese parámetro es optativo, o sea que a veces vas a querer el resultado sin que sea tenido en cuenta, yo suelo construir las consultas dentro del procedmiento, con condiciones en el where, de este tipo : Código:
select **** from *** where ***** and (:PRODUCTO is null or PRODUCTO = :PRODUCTO) Saludos.
__________________
Marc Guillot (Hi ha 10 tipus de persones, els que saben binari i els que no). |
#3
|
|||
|
|||
Si utilizas interbase te diría que jugases un poco con la clausula PLAN JOIN de la SELECT, de esta manera fuerzas tu el proceso de selección y ordenación con lo que puedes obtener o afinar los resultados.
Saludos
__________________
[Aprendiz]: Por que siempre hay algo nuevo que aprender. |
#4
|
|||
|
|||
Gracias por contestar
La solucion temporal que utilice fue crear una tabla a partir de mi StoreProcedure y de ahi todo bien, el problema es que paso todos los registros de la consulta del SP a la tabla y en algunos casos esto puede llegar a tardar un par de minutos. Siguiendo la sugerencia de Guillotmarc voy a probar agregarle los parametros de busqueda para ver si mejora en algo el rendimiento. Gracias, ya les contare como me fue |
#5
|
|||
|
|||
Que tal amigos, les cuento que probe la solucion que me dio Guillotmarc y me funciono a la perfeccion, excepto que cuando utilizo esta sentencia
AND ((:V_CLASIFICADOR IS NULL) OR (RTRIM(C.CLASIFICADOR) LIKE :V_CLASIFICADOR)) No me funciona cuando paso el parametro (V_CLASIFICADOR = '01%'), pero si lo coloco directamente si que puede estar pasando Gracias |
#6
|
||||
|
||||
Hola.
No sé que puede estar mal en tu consulta (a primera vista parece que todo esté bien). Aunque te aconsejo de cambiar la condición por : and (:V_CLASIFICADOR is null or C.CLASIFICADOR starting with :V_CLASIFICADOR) Ahora en el parámetro debes poner '01' en lugar de '01%'. La razón de que prefiera esta sintaxis, es porqué Interbase/Firebird podrá aprovechar un índice sobre el campo V_CLASIFICADOR en caso que exista. Cosa que no podía hacer con el Like. Nota: Tanto si usas el Like o el Starting with, el RTrim que haces no es necesario. Puesto que tu comparas el inicio de cadena del campo, y es indiferente si detrás hay espacios en blanco o no. (Y solo por el hecho de poner el RTrim probablemente ya estés impidiendo que se optimize la consulta con un índice). Saludos.
__________________
Marc Guillot (Hi ha 10 tipus de persones, els que saben binari i els que no). Última edición por guillotmarc fecha: 19-07-2003 a las 21:41:02. |
|
|
|