Foros Club Delphi

Foros Club Delphi (https://www.clubdelphi.com/foros/index.php)
-   SQL (https://www.clubdelphi.com/foros/forumdisplay.php?f=6)
-   -   Rapidez en consulta (https://www.clubdelphi.com/foros/showthread.php?t=63815)

mjjj 04-03-2009 01:14:38

Rapidez en consulta
 
Hola amigos, estoi teniendo hartos problemas con las consultas SQL, se estan demorando demasiado.

Espongo el codigo que utilizo, a ver si me pueden ayudar.

Código SQL [-]
select DISTINCT E.AREA, SUM(IIF(P.ESTADO ='A',1,0)),
SUM(IIF(P.ESTADO ='P',1,0)) from ESTRUCTURA E LEFT JOIN COMPRAS P
ON E.EMPRESA =P.EMPRESA AND E.AREA = P.AREA AND E.SUBAREA = P.SUBAREA
WHERE E.empresa = 'emp1'
GROUP BY E.AREA

La tabla Estructura, como su nombre lo dice, contiene la estructura de mi centro de costo, la tabla compras estan alojadas las compras, en donde el campo "estado", hace referencia a lo que necesito consultar.

Esta consulta esta demorando unos 10 segundos mas o menos, el asunto es que si cambio el LEFT JOIN, po INNER JOIN, anda de maravilla, instantaneo, pero solo me arroja las area de la tabla estructura y que ademas cohincida que tiene algun registro con el campo area.

Bueno lo que acabo de escribir es que realmente hace la funcion INNER JOIN, pero la que me interesa a mi es LEFT JOIN.

Alguien tiene alguna otra idea de como hace esta consulta de otra manera, y que vaya mas rapido.

Gracias

roman 04-03-2009 03:26:49

¿Tienes los índices adecuados? Por ejemplo, tu tabla compras debería tener índices en los campos que la relacionan con la de estructura.

// Saludos

mjjj 04-03-2009 05:29:40

nunca he utilizado los indices, utilizo IBExpert y Firebird 2.0.

Código SQL [-]
select DISTINCT E.AREA, SUM(IIF(P.ESTADO ='A',1,0)),SUM(IIF(P.ESTADO ='P',1,0)) from ESTRUCTURA E LEFT JOIN COMPRAS PON E.EMPRESA =P.EMPRESA AND E.AREA = P.AREA AND E.SUBAREA = P.SUBAREAWHERE E.empresa = 'emp1'GROUP BY E.AREA

Con el codigo que señalo, los indices en que tabla debieran ir? en estructura o compras?

Como debiera agregarse, que tipo de indice necesitare?

Ojala me puedan guiar para poder resolver este asunto.

Gracias

mjjj 05-03-2009 04:01:46

Amigos, no hay caso con este tema, por mas que busco e intento soluciones con logro aumentar la velocidad de la busqueda.

ALguna idea de como mejorar esto, lo que me interesa es que me arroje una lista con todas las distintas area, la suma del presupuesto y suma de compras. El asunto es que si utilizo inner join, funciona perfecto, pero no me arroja la totalidad de las areas, y al utilizar left join si que me arroja todas las areas, pero leeento.

He intentado con indices, vistas, etc. y no he podido mejorar esto.

Creo que no es algo tan complejo de realizar, mas bien, debiera ser un tema comun en consultas... 2 columnas una con las distintas area y la segunda la sumatoria de algo, indistintamente si hay o no registros en la segunda tabla.


Bueno amigos, espero me puedan ayudar ya que este tema me esta volviendo loko.

Muchas gracias

mjjj 05-03-2009 04:02:37

Amigos, no hay caso con este tema, por mas que busco e intento soluciones con logro aumentar la velocidad de la busqueda.

ALguna idea de como mejorar esto, lo que me interesa es que me arroje una lista con todas las distintas area, la suma del presupuesto y suma de compras. El asunto es que si utilizo inner join, funciona perfecto, pero no me arroja la totalidad de las areas, y al utilizar left join si que me arroja todas las areas, pero leeento.

He intentado con indices, vistas, etc. y no he podido mejorar esto.

Creo que no es algo tan complejo de realizar, mas bien, debiera ser un tema comun en consultas... 2 columnas una con las distintas area y la segunda la sumatoria de algo, indistintamente si hay o no registros en la segunda tabla.


Bueno amigos, espero me puedan ayudar ya que este tema me esta volviendo loko.

Muchas gracias

Kipow 05-03-2009 06:36:12

Coloca la estructura de las 2 tablas, a ver si podemos ayudar en algo. por lo pronto te digo que con indices podes mejorar mucho, podrias tambien modificar el PLAN. Para firebird yo utilizo el Interbase PLANalyzer y me ha servido mucho.

cdac901 22-03-2009 08:18:33

Hola creo que por la cantidad de datos, deberias realizar un procediemto almacenado

Código SQL [-]
CREATE PROCEDURE NEW_PROCEDURE
RETURNS(AREA VARCHAR(10),
        ESTADO_A INTEGER,
        ESTADO_P INTEGER) /* NO SE DE QUE TIPO SON LOS CAMPOS*/
AS
DECLARE VARIABLE V_ESTADO CHAR(1);
BEGIN
   ESTADO_A = 0;
   ESTADO_P = 0;

   FOR
       SELECT DISTINCT
              E.AREA,
              P.ESTADO
         FROM ESTRUCTURA E
    LEFT JOIN COMPRAS P
           ON ( (E.EMPRESA = P.EMPRESA) AND (E.AREA = P.AREA) AND (E.SUBAREA = P.SUBAREA) )
        WHERE E.EMPRESA = 'emp1'
         INTO :AREA,
              :V_ESTADO

   DO BEGIN
         IF (V_ESTADO = 'A') THEN
             ESTADO_A = 1;

         IF (V_ESTADO = 'P') THEN
             ESTADO_P = 1;

         SUSPEND;
      END
END


Luego de esto podrias hacer un sql con el resultado del procedimiento

Código SQL [-]
SELECT A.AREA, SUM(A.ESTADO_A), SUM(A.ESTADO_P) FROM NEW_PROCEDURE A

Agrega dos indices en la Tabla ESTRUCTURA campo ESTADO ascendente y descendente respectivamente, asi como los campos que estan despues del ON (E.EMPRESA, P.EMPRESA, E.AREA...)

Espero que te sirva

Cheerpipe 29-03-2009 03:44:01

Como dicen en la primera respuesta, una consulta que no usa indices, es una consulta destinada a morir XD..


select DISTINCT E.AREA, SUM(IIF(P.ESTADO ='A',1,0)),
SUM(IIF(P.ESTADO ='P',1,0)) from ESTRUCTURA E LEFT JOIN COMPRAS P
ON E.EMPRESA =P.EMPRESA AND E.AREA = P.AREA AND E.SUBAREA = P.SUBAREA
WHERE E.empresa = 'emp1'
GROUP BY E.AREA


Los siguientes campos deberian estar presentes en algun indice: (EMPRESA, AREA, SUBAREA), idealmente los 3 en 1 mismo indice si aplica, y otros indices con cada campo individual.
Yo tengo sistemas con consultas tremendamentes mas complejas, en tablas con miles y miles de registros y ninguna se ejecuta en mas de medio segundo, todo gracias a un correcto uso de indices.
Yo que tu me daria un tiempo para buscar informacion sobre un buen uso de indices en una base de datos, ya que conocerlos es algo simplemente indispensable.

Por ultimo, tambien hay que evitar la creacion exesiva de indices o de indices que no son necesarios, ya que la contraparte de estos es que disminullen la velocidad de consultas DML.


La franja horaria es GMT +2. Ahora son las 14:00:01.

Powered by vBulletin® Version 3.6.8
Copyright ©2000 - 2026, Jelsoft Enterprises Ltd.
Traducción al castellano por el equipo de moderadores del Club Delphi