Hola,
Cita:
|
Empezado por guillotmarc
El hecho de unir los dos procedimientos en uno solo, te va a proporcionar un aumento mínimo del rendimiento.
Yo no lo haría, sobretodo cuando está claro que tienes un problema de falta de índices.(Saltarse el procedimiento almacenado, solo valdria la pena si quieres pasar de un rendimiento de, pongamos 1.5 segunos a 1.0 segundos, pero no es el caso).
|
okis
Cita:
|
Empezado por guillotmarc
Tienes que estudiar el plan de ejecución de cada una de las consultas involucradas.
|
Bien, pero, ¿como hago esto?, ¿hay alguna herramienta que pueda utilizar?
Cita:
|
Empezado por guillotmarc
Utiliza SQL'92 y no SQL'89 (creo).
|
Perdón por mi torpeza pero, ¿como sé cual estoy usando, y en tal caso, como lo cambio?, ¿que implica tener uno u otro?
Cita:
|
Empezado por guillotmarc
Estás creando un producto cartesiano :
Código:
select distinct
renopla2.NUMALU, renopla2.nombre, renopla2.TELFALU, renopla2.nomcli,
renopla2.fecfincurso, grupos.alias
from renopla2 EXTE, grupos
where (( select count (*) from renopla2 inte
Where inte.numalu=exte.numalu)=1 )
and (renopla2.aliascomen=grupos.alias)
ORDER BY renopla2.NUMALU, renopla2.fecfincurso desc
El Optimizador va a tener dificultades en optimizar esto. Con los INNER JOIN y LEFT OUTER JOIN del SQL'92 te queda un código mucho más legible, y ayudas al optimizador.
Saludos. |
¿donde estoy creando un producto cartesiano?
Perdona pero, ¿me lo puedes aclarar algo más?
Muchas gracias por todo,
Virginia