Re: Pregunta NUMERIC vs REAL-FLOAT

El 25/08/05, Paolo Lopez<murphyperu(at)gmail(dot)com> escribió:
> Hola a todos.

Hola.

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

mientras mas leas más aprenderas, y esa es la idea (bueno, mi idea).

saludos.

> 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)
> > >
> >
>
> ---------------------------(fin del mensaje)---------------------------
> TIP 1: para suscribirte y desuscribirte, visita http://archives.postgresql.org/pgsql-es-ayuda
>

--
Solo soy una mente genial en un cuerpo hermoso.
Profesión: Jugar a ser Programador.