Skip site navigation (1) Skip section navigation (2)

Re: Retornar 0 cuando no existen ocurrencias en consulta

From: "Jaime Casanova" <systemguards(at)gmail(dot)com>
To: "Yessica Brinkmann" <yessica(dot)brinkmann(at)gmail(dot)com>
Cc: postgresql <pgsql-es-ayuda(at)postgresql(dot)org>
Subject: Re: Retornar 0 cuando no existen ocurrencias en consulta
Date: 2006-02-28 07:47:02
Message-ID: c2d9e70e0602272347u5faf1d34q415ec15ad549e7ec@mail.gmail.com (view raw or flat)
Thread:
Lists: pgsql-es-ayuda
cc:lista... son las 3am y tengo pereza de leer los mails

On 2/27/06, Yessica Brinkmann <yessica(dot)brinkmann(at)gmail(dot)com> wrote:
>
> Hola. Soy Yessica otra vez...
>
> Ya probé COALESCE(...,0) y funciona perfectamente siempre y cuando no use
> grouop by...no sé porqué...
> Yo necesito hacer un listado por productores como ya te había dicho...y
> hallar el ingreso para cada productor en un trimestre específico y también
> para el mismo trimestre en el año anterior, todo en un solo sql...por lo
> tanto necesito usar el group by...para agrupar los resultados por
> productor...
>
>
> Gracias.
>
> Yessica Brinkmann.
>
>
>
>
> El día 25/02/06, Jaime Casanova <systemguards(at)gmail(dot)com> escribió:
> > On 2/24/06, Yessica Brinkmann <yessica(dot)brinkmann(at)gmail(dot)com > wrote:
> > > Conozco LEFT OUTER JOIN. Normalmente no me gusta mucho usarlo; en
> realidad,
> > > ni siquiera suelo usar los join simples, ya que trato de usar
> normalmente un
> > > sql que sea digamos "genérico", es decir, que funcione para cualquier
> > > gerenciador, sea este Postgres, SQLServer, Oracle, etc., ya que la
> empresa
> > > en la que trabajo este es siempre un requerimiento de desarrollo.
> > >
> >
> > En ese caso no te aconsejaria usar subconsultas en el from (no se
> > Oracle pero me parece recordar que SQL Server no lo maneja), en lugar
> > de eso mejor usa una vista
> >
> > > Sé que el valor retornado no es precisamente null, sino que no hay
> > > ocurrencias.
> >
> > has probado con coalesce?
> >
> > (
> >   select coalesce(sum(productividad.total_gs::decimal), 0) as monto_ant
> >   from productor,productividad
> >   where productividad.fecha >'2002/10/1'AND productividad.fecha
> <'2002/12/31'
> >   and productividad.cod_productor=productor.cod_productor
> >   group by productor.nombres, productor.apellidos
> > ) as subtable
> >
> > Aunque a decir verdad no entiendo bien tu query, por ejemplo:
> >
> > 1) como se relaciona esta subconsulta con tu query principal?
> > 2) que diferencia existe entre el sum que haces en la subconsulta y el sum
> que
> >    tienes en el query principal?
> > 3) cual es la idea de hacer un group by por productor.nombres,
> > productor.apellidos
> >    en la subconsulta?
> >
> > Si no me equivoco, no lo he probado porque no estoy en mi maquina aun,
> > tu subconsulta esta generando un producto cartesiano
> >
> > <-- query original -->
> >
> > select productor.nombres || ' ' || productor.apellidos as productor,
> > companhia.nombre as companhia,
> > distrito.nombre as distrito,
> > departamento.nombre as departamento,
> > sum(productividad.total_gs::decimal ) as monto,
> > subtable.monto_ant as monto_ant
> > from productor, companhia, distrito, departamento, productividad,
> > (
> >   select sum( productividad.total_gs::decimal) as monto_ant
> >   from productor,productividad
> >   where productividad.fecha >'2002/10/1'AND productividad.fecha
> <'2002/12/31'
> >   and productividad.cod_productor=productor.cod_productor
> >   group by productor.nombres, productor.apellidos
> > ) as subtable
> > where productividad.fecha >'2005/10/1'AND productividad.fecha
> <'2005/12/31'
> > and productor.cod_companhia=companhia.cod_companhia
> > and productor.cod_distrito=distrito.cod_distrito
> > and productor.cod_dpto=departamento.cod_depto
> > and productividad.cod_productor=productor.cod_productor
> > group by productor.nombres, productor.apellidos, companhia.nombre,
> > distrito.nombre, departamento.nombre, subtable.monto_ant
> >
> > <--   -->
> >
> > --
> > Atentamente,
> > Jaime Casanova
> >
> > "What they (MySQL) lose in usability, they gain back in benchmarks, and
> that's
> > all that matters: getting the wrong answer really fast."
> >                           Randal L. Schwartz
> >
>
>


--
Atentamente,
Jaime Casanova

"What they (MySQL) lose in usability, they gain back in benchmarks, and that's
all that matters: getting the wrong answer really fast."
                           Randal L. Schwartz

In response to

Responses

pgsql-es-ayuda by date

Next:From: Jaime CasanovaDate: 2006-02-28 07:47:28
Subject: Re: Retornar 0 cuando no existen ocurrencias en consulta
Previous:From: Alvaro HerreraDate: 2006-02-28 00:39:31
Subject: Re: Tiempo de vida de las conexiones

Privacy Policy | About PostgreSQL
Copyright © 1996-2014 The PostgreSQL Global Development Group