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

Pregunta NUMERIC vs REAL-FLOAT

From: Paolo Lopez <murphyperu(at)gmail(dot)com>
To: pgsql-es-ayuda(at)postgresql(dot)org
Subject: Pregunta NUMERIC vs REAL-FLOAT
Date: 2005-08-25 16:57:14
Message-ID: ab97ec2005082509577732a3ce@mail.gmail.com (view raw or flat)
Thread:
Lists: pgsql-es-ayuda
Hola a todos.

He revisado en el link que me mandas, y si es verdad todo esta ahi,
pero son bastantes mails q leer. Alguna ayudita de en q mes podria
encontrar esa informacion ??

Si pudieran darme mas luces con lo del NUMERIC en vez de REAL-FLOAT 
seria de gran ayuda, estoy ya casi terminando con las pantallas de
pagos.


Paolo.





On 8/25/05, Juan Romero <jgromero(at)gmail(dot)com> wrote:
> > Me dices que ya se ha hablado de este tema en la lista, pero yo soy
> > nuevo en ella.
> >
> Para que revises los hilos de conversación anteriores a tu adhesión a
> la lista, revisa los archivos:
> 
> http://archives.postgresql.org/pgsql-es-ayuda/
> 
> Juan Romero
> 




On 8/24/05, Paolo Lopez <murphyperu(at)gmail(dot)com> wrote:
> Hola a todos.
> 
> Con respecto a lo del SELECT FOR UPDATE para tratar de salvar lo de la
> concurrencia en la obligacion de pago me ha quedado claro. Muchas
> gracias por la ayuda  :)
> 
> Con dicha idea, he leido algo mas acerca de la opcion por defecto
> "READ COMMITTED" en lo que es transacciones en postgres, que lo que
> hace en el caso de update o delete bloquea el(los) row(s) pedido(s)
> hasta que la transaccion termine (commit o rollback). Con ello estoy
> ampliando aun mas la solucion a mi problema.
> 
> Una consulta mas, aprovechando los muy buenos comentarios dados para
> mi tabla que estoy diseñando. Cuando me dices :
> 
> > Otro tema que ya se ha comentado antes en la lista es que es mala idea
> > almacenar valores de moneda en campos de punto flotante; es mejor usar
> > NUMERIC(x, y) con valores apropiados de x e y (generalmente y=2).
> 
> Si he leido en los "data types" del postgres sobre este tipo de dato.
> Pero a mi parecer pareciera que uno se "encasilla" cuando define :
> 
> NUMERIC(precision, scale)
> 
> ya que si la cantidad de digitos enteros es =  precision - scale ,
> hace que uno siempre trabaje con esa cantidad. Pero, y si cambia en
> algun momento la cantidad de enteros ??. Por eso es que no me he
> decidido aun a utilizar el  NUMERIC  y estoy con lo del  REAL.
> 
> Me dices que ya se ha hablado de este tema en la lista, pero yo soy
> nuevo en ella.
> 
> Agradeceria que me ampliaran sobre este tema, PLZ.
> 
> 
> Gracias nuevamente.
> 
> Paolo.
> 
> 
> 
> 
> 
> On 8/20/05, Alvaro Herrera <alvherre(at)alvh(dot)no-ip(dot)org> wrote:
> > On Sat, Aug 20, 2005 at 04:52:43PM -0500, Paolo Lopez wrote:
> >
> > > Para obligaciones de pago :
> > >
> > > llaves primarias :
> > > idObligacion  integer
> > >
> > > otras llaves:
> > > nombreObligacion  text
> > > fechaVcto date
> > > monto Real
> > > tipoBanco integer
> > > tipoPresencial integer
> > > moraxDia  Real
> > > montoMora Real
> > > fechaCancelacion date
> > > montoCancelacion Real
> > > cancelado integer
> > > anulado integer
> >
> > No entiendo por que "cancelado" y "anulado" son integers -- que es lo
> > que guardas ahi?  Si son valores booleanos, deberias usar campos de tipo
> > booleano.
> >
> > Otro tema que ya se ha comentado antes en la lista es que es mala idea
> > almacenar valores de moneda en campos de punto flotante; es mejor usar
> > NUMERIC(x, y) con valores apropiados de x e y (generalmente y=2).
> >
> >
> > > La regla de pago se resume en :
> > > 1) solo cancelar si no esta anulado.
> > >
> > > a lo que la regla 1) podria extenderla a
> > > 1.1) solo cancelar si no esta anulado y no esta cancelado.
> > > 1.2) solo anular si no esta anulado.
> >
> > El protocolo de pago seria una funcion en plpgsql similar a
> >
> > select into rec * from obligaciones
> >   where idObligacion=<llave>
> >   for update of obligaciones;
> >
> > if rec.cancelado = true
> >   raise exception 'ya esta cancelado'
> > elsif rec.anulado = true
> >   raise exception 'ya esta anulado'
> > endif
> >
> >
> > Etc.  Si lo haces de esta manera no tienes problemas de concurrencia,
> > puesto que el lock que se toma al hacer SELECT FOR UPDATE significa que
> > un solo proceso va a poder estar modificando una obligacion de pago en
> > un momento dado; cualquier otro va a tener que esperar hasta que ese
> > haya comprometido su modificacion, y cuando pueda ver el nuevo registro,
> > ya va a estar marcado como anulado o cancelado.
> >
> >
> > Otra cosa: por favor cuando respondas mensajes de la lista, hazlo
> > siempre en la lista (con copia a la lista).  Gracias.
> >
> > --
> > Alvaro Herrera (<alvherre[a]alvh.no-ip.org>)
> > "In a specialized industrial society, it would be a disaster
> > to have kids running around loose." (Paul Graham)
> >
>

Responses

pgsql-es-ayuda by date

Next:From: Pablo BraulioDate: 2005-08-25 17:09:24
Subject: Ver columnas de una tabla.
Previous:From: Carlos MoraDate: 2005-08-25 15:55:18
Subject: como recuperar el tamaño de campos, desde VB

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