Re: tabla que se consulta sobre si misma

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