Pregunta NUMERIC vs REAL-FLOAT

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)
> >
>