From: | "Eduardo Arenas C(dot)" <edomax(at)gmail(dot)com> |
---|---|
To: | Virginia <mavir78(at)gmail(dot)com> |
Cc: | pgsql-es-ayuda <pgsql-es-ayuda(at)postgresql(dot)org> |
Subject: | Re: tabla que se consulta sobre si misma |
Date: | 2014-06-10 18:21:36 |
Message-ID: | CAEe4h9qkZT9eeBFxYbDc_6BTiuZU_9-R_fi++jFg+=SMNeYeuQ@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-es-ayuda |
Virgina,
En realidad no hay un unico camino para solucionar tu problema, y la
solución definitiva va a depender si es que necesitas esto como un
informe o es una consulta periodica del motor operacional, donde
tendrías que ver que es lo mas adecuado segun tu necesidad.
De igual forma, hice una prueba con una tabla similar a la tuya que
contiene 40 millones de registros y la consulta que te envié:
i) no arroja la misma cantidad de registros la consulta con with
recursive las notas en blanco.
ii) intente optimizar al maximo cada una de las consultas y consulta
con with recursive no logra bajar de 7000 ms para procesar y entregar
los datos en pgadmin. y la consulta que te envie, en la primera
consulta demoró 20.000 ms, pero ya en la segunda y tecera, cuarta,
etc.. consulta demora 700 ms
En realidad no se que es mejor, que siempre demore 7 seg, o que la
primera vez demore 20 seg y luego menos de 1 segundo.
En mi caso la consulta tiene 7000 clientes, y en el mes espcífico que
consulte tengo 500 mil notas aprox.
Saludos
Eduardo
El 10 de junio de 2014, 8:51, Virginia<mavir78(at)gmail(dot)com> escribió:
>
> Buen día. Gracias por tu ayuda.
> Después de buscar con detenimiento, leí lo del WITH RECURSIVE, lo que funciona a la perfección, (eso creo)
>
> WITH RECURSIVE tareas(empid, notareas_id) AS
> (
> (
> SELECT empid, notareas_id
> FROM cp2_notas_tareas
> WHERE categorias_nt_id = 10 AND status_empid is null AND to_char(DATE(fecha_vencimiento) ,'yyyy-mm') = '2014-05'
> )
> UNION ALL
> (
> SELECT cp2_notas_tareas.empid, cp2_notas_tareas.notareas_id
> FROM cp2_notas_tareas, tareas
> WHERE (cp2_notas_tareas.tarea_id = tareas.notareas_id) AND cp2_notas_tareas.categorias_nt_id = 10
> AND to_char(DATE(cp2_notas_tareas.fecha_vencimiento) ,'yyyy-mm') = '2014-05'
> )
> )
>
> SELECT distinct(empid), max(notareas_id)
> FROM cp2_notas_tareas NATURAL JOIN tareas GROUP BY cp2_notas_tareas.empid ORDER BY empid;
>
> -------------------------------------------
> Ing. Maria Virginia Porras B.
> -------------------------------------------
>
>
> El 9 de junio de 2014, 18:51, Eduardo Arenas C. <edomax(at)gmail(dot)com> escribió:
>
>> Virgina, prueba esto debería servir
>>
>> select a.*
>> ,(select b.fecha_registro
>> from tareas_notas as b
>> where b.tipo=2
>> and b.categorias_nt_id=100
>> and b.fecha_registro between '20140501' and '20140531'
>> and a.empid = b.empid
>> order by 1 desc limit 1
>> ) as ultima_nota_fecha
>> ,(select b.descripcion
>> from tareas_notas as b
>> where b.tipo=2
>> and b.categorias_nt_id=100
>> and b.fecha_registro between '20140501' and '20140531'
>> and a.empid = b.empid
>> order by 1 desc limit 1
>> ) as ultima_nota_descripcion
>> from
>> (select distinct a.empid
>> from tareas_notas as a
>> where fecha_registro between '20140501' and '20140531') as a
>>
>> saludos
>>
>>
>>
>> El 5 de junio de 2014, 12:23, Virginia<mavir78(at)gmail(dot)com> escribió:
>>
>>>
>>> Buenas tardes foro.
>>>
>>> Les escribo para ver si me pueden aportar ideas sobre cómo resolver el enredo que tengo con consultas sobre una tabla que almacena registros "padres" e "hijos" simultáneamente.
>>> La tabla es la siguiente:
>>>
>>> tareas_notas
>>> (
>>> notareas_id serial NOT NULL,
>>> empid integer,
>>> fecha_registro
>>> fecha_ocurrencia
>>> responsable integer,
>>> supervisor integer,
>>> fecha_vencimiento, -- Fecha tope para realizar la tarea
>>> status_id integer, -- Controla el estatus de las tareas. Las notas se consideran mas una observación, no deriva una acción secundaria
>>> tarea_id integer, -- id de la tarea padre
>>> tipo integer, -- indica si el registro es nota o tarea según el valor (libreria valores)
>>> descripcion text,
>>> user_creador integer,
>>> categorias_nt_id integer,
>>> relacion_nt integer,
>>> user_realiza integer, -- Puede ser el responsable u otro de la coordinación
>>> fecha_cierre timestamp without time zone, -- fecha de cierre de la tarea,
>>> no_renovacion integer, -- id del motivo de la no renovación, el valor viene de tabla motivos
>>> CONSTRAINT tareas_notas_pkey PRIMARY KEY (notareas_id)
>>> )
>>>
>>> Les pongo en contexto:
>>> Una nota o una tarea, solo existen si están "amarradas" a una empresa.
>>> En un mes, (tiempo máximo en que se monitorea la gestión de tareas) puede haber mas de una tarea para la misma empresa.
>>> Un registro puede ser de tipo 1: tarea o tipo 2: nota
>>> Una tarea debe tener una nota asociada como indicativo de que ésa tarea fue realizada.
>>> Una nota que es un cierre de una tarea, es de tipo 2 con tarea_id distinto de 0.
>>> Una nota que se agrega como una simple observación es de tipo 2 con tarea_id = 0.
>>> Una tarea, es registrada con un id de categoria y a lo largo del mes, éste id puede variar.
>>>
>>> Ahora bien, en un principio, lo que no consigo resolver es cómo obtener la última tarea del mes con categoria 100 para la empresa X.
>>> ¿Alguien me da una idea?
>>>
>>> Gracias por la ayuda que puedan prestarme
>>
>>
>>
>>
>> --
>> Eduardo Arenas Castillo.
>> +56 9 6629 1618
>>
>
--
Eduardo Arenas Castillo.
+56 9 6629 1618
-
Enviado a la lista de correo pgsql-es-ayuda (pgsql-es-ayuda(at)postgresql(dot)org)
Para cambiar tu suscripcin:
http://www.postgresql.org/mailpref/pgsql-es-ayuda
From | Date | Subject | |
---|---|---|---|
Next Message | raul andrez gutierrez alejo | 2014-06-10 20:14:45 | Problema de espacio en disco duro postgres sobre windows |
Previous Message | Eduardo Arenas C. | 2014-06-10 17:09:22 | Re: Postgresql con cituddb para sistemas analiticos |