Optimizar LEFT JOIN
 

Hola
Les escribo porque no encuentro de mejorar el rendimiento de la siguiente consulta SQL:

Código SQL [-]
Select CURRENT_DATE AS FECHA, t.codtiendah,t.nomh,h.codor,
h.descripcion,h.codh,t.codigo,s.stock
from auxh h
 left join Articulos a
 on a.codoperador=h.codor
 inner join tiendasip t
 on t.codigo=:xcod
 left join stockarticulos s
 on (a.codigo=s.codarticulo)and(t.codigo=s.codtienda)
order by h.codorden

la cuestion es que sin realizar el ultimo left join el rendimiento es optimo pero con el se dispara el consumo de tiempo. He estado buscando otras opciones y todas me llevan a un tiempo similar.
Gracias por atenderme

Sin conocer cual es el motor que usas, tener una idea de las estructuras de las tablas, y del por que está diseñada la consulta de esta manera, es imposible dar una respuesta atinada.

En esto de las bases de datos, pocas cosas son absolutas. :)

¿es realmente necesario hacer un left join?

Hola jachguate
El motor de base de datos es Firebird, las tablas no tienen nada en especial y si que necesito utilizar el left join ya que necesito que aparezcan todos los registros de la tabla auxh aunque no esten relacionados con las otras tablas.
En realidad el problema creo que viene de ahí porque si cambio el ultimo left join por un inner join la consulta se realiza muy rapida, aunque no me da loq ue necesito :)

¿que es lo que necesitas?

Pregunto, porque simplemente para que aparezcan todos los registros de la tabla auxh, no me parece necesario el último left join...

Hasta luego.

Tambien pensaba eso mismo yo pero cambiandolo por un inner join hay registros que no aparecen

bien. Veo que no queres dar mas información. Lamentablemente, no traje mi varita mágica. Quizás alguien mas.. :D

Hasta luego.

;)

A que te refieres con mas información?? Lo unico que preguntaba es si sabiais alguna manera de optimizar la consulta, pero bueno gracias por tu tiempo.

Creo que sin saber que quieres obtener difícilmente te podemos ayudar incluso a crear una nueva consulta, por ejemplo, veo tu código y no entiendo que deseas obtener, si nos lo expresas en "español" tal vez y digo, tal vez, tu sentencia no es adecuada y se puede solucionar de otra forma.

Ten en cuenta que no conocemos la estructura de tus tablas y así es como dar "palos de ciego".

Salud OS

Bueno, ponete en mis zapatos... ¡no tengo idea de lo que querés hacer!. Vos la tenes muy clara... por eso obvias muchos detalles. Por eso te referí al hilo de la calidad de las preguntas, que no creo que hayas leido todavía.

¿que datos están almacenados en la tabla auxh?
¿que datos están almacenados en la tabla tiendasip?

Si no tenemos su estructura, al menos entender que es cada una.

Luego, ¿que índices tienen las tablas?

Finalmente, ¿que información esperas obtener de vuelta?

Esto porque quizás no haya forma de optimizar esta consulta que vos estas planteando... pero quizás se pueda plantear una consulta diferente, que devuelva la información que precisás, pero que sea mas óptima.

No se... la tarea de darse a entender no es mia... es tuya, así que si yo fuera vos, pensaría que mejor dar información de sobra y no de falta.

Es probable que en la mitad del tiempo (o menos) que he invertido para explicarte estas cosas, hubiese planteado una solución a tu problema. En cambio, voy a comer, luego a una junta... y quizás no tenga el ánimo de volver a ver el hilo, o simplemente podría morir hoy por la tarde ¿por que correrte ese riesgo si ya hubo alguien dispuesto a ayudarte? :confused: :confused:

Ok oido cocina he leido el Tema calidad en las preguntas y estoy de acuerdo.
Siento haber sido poco claro en la pregunta.

La tabla tiendasip no es importante a mi entender en esta consulta pues solo se utiliza para recopilar un par de campos, y aun eliminandola de la consulta el retardo se mantiene.
El problema a mi entender viene porque las tablas auxh y stockarticulos no estan relacionadas directamente y se requiere de la tabla articulos como tabla intermedia. Además, es necesario que aparezcan todos los registros de la tabla auxh, aunque no aparezcan en la tabla stockarticulos (de ahí los dos left join utilizados).
No utilizo indices en las tablas por cierto.
Vamos que esta consulta seria equivalente:

Código SQL [-]
Select CURRENT_DATE AS FECHA,h.codor,
h.descripcion,h.codh,a.codigo,s.stock
from auxh h
left join articulos a
on (a.codoperador=h.codor)
left join stockarticulos s
on (s.codarticulo=a.codigo)and(s.codtienda=:xcodtienda)
order by h.codorden

Las Tablas son:
auxh
CODIGO INTEGER,
CODORDEN INTEGER,
CODOR VARCHAR(50),
DESCRIPCION VARCHAR(100),
CODH VARCHAR(25)
articulos
CODIGO INTEGER,
CODOPERADOR VARCHAR(50)
stockarticulos
CODIGO INTEGER,
CODARTICULO INTEGER,
CODTIENDA INTEGER,
STOCK DOUBLE PRECISION

Pues ya los estás creando, crea indices con los campos por los cuales se enlazan las tablas y por aquellos que quieras realizar una ordenación.

Una vez hecho esto si la cosa sigue lenta tendremos que esperar que jachguate no se haya muerto el otro día por la tarde para que nos ilumine con su sabiduria :rolleyes::D.

Un saúdo.

No hace falta crear un índice por aquellos campos que son parte de una llave foránea, pues para estos el motor crea automáticamente uno al declarar la regla de integridad.

¡Te tengo malas noticias!.... resulta que acá en el cielo también hay conexión a Internet... parece que no se librarán de mi en el club... :D :D :D

Con respecto del tema del hilo, si solo se pretende que aparezcan *todos* los registros de la tabla auxh, no entiendo por qué se hacen dos left join y no solo uno.

Tampoco veo por que razón se coloca la condición (s.codtienda=:xcodtienda) como parte del join, pues a mi entender esta debiera ir en el where. Aún cuando el resultado pueda ser el mismo, la semántica es distinta.

Hasta luego.

;)

Di por hecho que no tenía claves foráneas :p, para las claves primarias tampoco haría falta crearlos.

Sandiano, yo te recomendaría que mirases algo de procesamiento y optimización de consultas, para poder optimizar el diseño, y por tanto el rendimiento, de la base de datos, así como calcular el coste de dichas consultas.



No vivas engañado, eso es que estás en el infierno :D:eek:

Un saúdo