Foros Club Delphi - Filtro con muchas relaciones JOIN

Foros Club Delphi (https://www.clubdelphi.com/foros/index.php)

- SQL (https://www.clubdelphi.com/foros/forumdisplay.php?f=6)

- - Filtro con muchas relaciones JOIN (https://www.clubdelphi.com/foros/showthread.php?t=18274)

Filtro con muchas relaciones JOIN

Hola a todos...
Les planteo el problema...
Tengo 5 tablas relacionadas por join de la siguiente manera

select campo1,campo2, ... from
tabla1 inner join tabla2 on
tabla1.campo = tabla2.campo
inner join tabla3 on ...

y lo que tengo que hacer el filtrar por un campo que esta en la ultima tabla (tabla5.campo)

si en la clausula where incorporo TABLA5.campo = valor la consulta se demora 24 seg que creo que es mucho. Si no filtro, es decir..si no pongo el filtro TABLA5.campo = valor la consulta es casi inmediata. No se por que pero de alguna manera al filtrar se demora mucho...

Me pregunta es...hay alguna forma de obtimizar la consulta filtrada para que no se demore tanto??
todas las tablas tienen indice primario o foraneo...
Muchas gracias....

¿Puedes poner la consulta completa?
¿Cuantos campos tienes en las tablas? (para hacernos una idea)
¿Todas las tablas tienes PK definida?
¿Los campos de JOIN son numéricos (es más rápido)? ¿Y tienes índices definidos por esos campos?
¿De qué tipo es el campo de filtro?

Las tablas:
VENTAS : Tabla de ventas
VENTAS_ASO : asociacion de ventas..aqui estan los articulos que componen una venta.
ARTICULOS: Cada articulo esta asociado a un item
ITEMS : Cada Item esta asociado a un Subrubro
SUBRUBRO : Cada subrubro esta asociado a un Rubro
RUBROS: No la incorpora en la consulta por que no hace falta, filtro usando la FK de SUBRUBROS.

La cantidad de campos por tabla es:
VENTAS : 24 campos
VENTAS_ASO : 12
ARTICULOS : 27
ITEMS : 5
SUBRUBROS : 5

Código:

select sr.codigosubrub, sr.descri,

sum(cast(va.cantid as float)*va.precioventa) as total

,sum(va.cantid) as cantidad

from ventas v inner join ventas_aso va on

   v.codigoventa=va.codigoventa

   and v.codigosucurs=va.codigosucurs

inner join articulos a on

   va.codigoarticu=a.codigoarticu

inner join items i on

   a.codigoitem=i.codigoitem

inner join subrubros sr on

   i.codigosubrub=sr.codigosubrub

where

CAST(v.fecha as date) between '01.01.2005' and '31.01.2005'

and v.codigosucurs=2

and sr.codigorubro=1

group by sr.codigosubrub,sr.descri

order by 3 descending

Todos las tablas tienen PK y FK con indices en cada caso.
Todos los campos clave son integer.
y estoy filtrando por un campo que es clave foranea de tipo integer (sr.codigosubrub)

Ahora , habiendo planteado un poco mas al detalle....
Cuando aplico

Código:

 

sr.codigorubro=1

la consulta se demora 24 seg...si esto no esta se demora solo 1 seg....que pasa??

Muchas gracias por el tiempo dedicado..

OK, no veo nada raro (PK, indices, INNER JOIN y FK's, son correctos).

COMENTARIO: Me refería a los registros de cada tabla, no a los campos de cada tabla, de todas formas a no ser que tengas muchos, no veo lógico tal incremento.

¿Qué Base de Datos estás usando?
¿Puedes ver el plan de ejecución?

ventas : 12000 reg
ventas_aso: 20000
articulos : 7000
items: 800
subrubros : 80

Te escribo el plan de ejecucion..quizas a vos te dice mas que a mi..y me contas que ves de raro....

Código SQL [-]PLAN SORT (SORT (JOIN (VA INDEX (RDB$PRIMARY50),
 V INDEX (RDB$PRIMARY49),SR INDEX (RDB$FOREIGN94),
 I INDEX (RDB$FOREIGN75),A INDEX (RDB$PRIMARY3,RDB$FOREIGN52))))

Uso Interbase 7 ...

Hice otro prueba...cuando me daba 24 seg la consulta lo hacia corriendo desde el mismo servidor de la base de datos. Cuando lo ejecuto desde un cliente la misma consulta me da 29 seg...5 seg mas...ES INCREIBLE!!!!

Que hacemos gente? Le echamos la culpa a Interbase???

Saludos y gracias por su tiempo

Cita:

Empezado por FlacoNet

ventas : 12000 reg
ventas_aso: 20000
articulos : 7000
items: 800
subrubros : 80
Que hacemos gente? Le echamos la culpa a Interbase???

De verdad que ahora me has dejado "de piedra";
* 80 registros y al añadir un WHERE sobre ese campo tarda 24 sg. No lo entiendo; De verdad que no tiene ni lógica ni sentido. El plan de ejecución en ambos casos debería ser casi idéntico, simplemente que al final debería hacer el filtrado. ¿?¿?¿?¿?¿?¿

¿Tal vez un BUG? Aunque me cuesta pensarlo,... tampoco es una consulta tan complicada.
No tendrás tablas corruptas o alguna cosa por el estilo...
¿Has probado a hacer un Backup/Restore de la BD? No es que piense que vaya a resolver nada, pero es lo que yo haría.

(1) Descarto por los datos que das, que esa consulta en condiciones normales tarde eso.
(2) Descarto que sea un BUG de IB (a éstas alturas)
(3) ==> Por tanto hay que probar otras cosas:
* Si estás lanzando la SQL desde un programa, lánzala desde la consola.
* Backup/Restore de la BD, por si hay algun problema.
* Otras pruebas con datos:
* Borra todos los registros de la tabla sr y prueba.
* Prueba con WHERE sobre otras tablas (para ver si es problema de esa o de otra...)
* ....

Siento no poder ayudarte más, pero es que no lo acabo de enterder, no tiene sentido... :(

Perdon por no haber respondido antes.

Llegue a la solucion haciendo un backup y luego un restore de la base de datos...

la base de datos tenia 60 MB y despues del restore quedo solo con 6 MB. De esta manera la consulta se realiza en pocos segundos.

Saludos y gracias