Recalculo de saldo

Hola Maxi:

1.- Esa tabla no está normalizada, la columna "saldo" es completamente
innecesaria y sólo se usa en la capa de presentación (Es una cuenta T de
Contabilidad).
2.- El tener una columna saldo asume que nadie va a insertar un registro con
una fecha anterior e invalidar todos los saldos posteriores.
Se presentan problemas de integridad de información; si no, ¿por qué
necesitaría hacer un UPDATE como ese?
3.- Las soluciones para realizar semejante UPDATE no escalan adecuadamente;
con tablas grandes, un cursor tal vez sea más apropiado que una solución de
O(n^2) como la que le propuse.

Pero en fin, cada cabeza es un mundo, como decimos por acá.
¿Cuáles son tus razones para usar un diseño como ese?

Saludos,
Eric Garza
AMIGE

"MAXI" wrote in message
news:

Eric, creo que la mejor forma es justamente hacerlo en la BDD mientras

esto

no haga cursores claro esta!!

En que te basas para decir que no es para la BDD? porque yo creo que
justamente este tipo de cosas dentro de un SP son lo ideal

1.- Esa tabla no está normalizada, la columna "saldo" es completamente
innecesaria y sólo se usa en la capa de presentación (Es una cuenta T de
Contabilidad).

Es claro que no está normalizada. Sin embargo a veces hay que
desnormalizar para agilizar cosas. Aunque en este
caso en particular no creo que sea el mejor diseño.

2.- El tener una columna saldo asume que nadie va a insertar un registro

con

una fecha anterior e invalidar todos los saldos posteriores.
Se presentan problemas de integridad de información; si no, ¿por qué
necesitaría hacer un UPDATE como ese?
3.- Las soluciones para realizar semejante UPDATE no escalan

adecuadamente;

con tablas grandes, un cursor tal vez sea más apropiado que una solución

de

O(n^2) como la que le propuse.

Pero en fin, cada cabeza es un mundo, como decimos por acá.
¿Cuáles son tus razones para usar un diseño como ese?

Yo pienso que él no necesita guardar la columna saldo pero sí que puede
tener un SP o función DENTRO de la BD que le devuelva el valor dado el
parámetro de la cuenta y la fecha. Puede incluso tener indices sobre
cuenta,fecha.

Otra manera puede ser tener una vista indexada que resuma por cuenta y mes.
Entonces para calcular un saldo a una fecha puede sumar los meses previos a
la fecha actual y luego los movimientos del mes actual. Todo también en un
SP dentro de la BD.


Saludos

ERic, estoy totalmente de acuerdo contigo en lo que decis del diseño, pero
como has puesto que este tipo de operaciones no son para hacer en la BDD, me
dio la sensacion de que hablas de armar una DLL y no usar SP.




Maxi

Buenos Aires - Argentina
Desarrollador .NET 3 Estrellas
Microsoft User Group (MUG)
Mail: Maxi_accotto[arroba]speedy.com.ar

Msn Messenger:

"Eric Garza" escribió en el mensaje
news:

Hola Maxi:

1.- Esa tabla no está normalizada, la columna "saldo" es completamente
innecesaria y sólo se usa en la capa de presentación (Es una cuenta T de
Contabilidad).
2.- El tener una columna saldo asume que nadie va a insertar un registro
con
una fecha anterior e invalidar todos los saldos posteriores.
Se presentan problemas de integridad de información; si no, ¿por qué
necesitaría hacer un UPDATE como ese?
3.- Las soluciones para realizar semejante UPDATE no escalan
adecuadamente;
con tablas grandes, un cursor tal vez sea más apropiado que una solución
de
O(n^2) como la que le propuse.

Pero en fin, cada cabeza es un mundo, como decimos por acá.
¿Cuáles son tus razones para usar un diseño como ese?

Saludos,
Eric Garza
AMIGE

"MAXI" wrote in message
news:

Eric, creo que la mejor forma es justamente hacerlo en la BDD mientras

esto

no haga cursores claro esta!!

En que te basas para decir que no es para la BDD? porque yo creo que
justamente este tipo de cosas dentro de un SP son lo ideal

Si

Leandro Sponton
Goya - Argentina

Hola, nuevamente por aqui ;-)

No compoarto contigo que un cursor sea mejor!! todo lo contrario!! un cursor
hara un recorrido entero de la tabla de una forma muy particular y si ademas
este cursor esta dentro de una transaccion y es pesado el proceso, bueee que
los demas usuarios por ese lapso se olviden de usar el sistema ;-)

Que no esta normalizada es verdad, pero quien dijo que todo debe estar
normalizado? hay ocaciones donde desnormalizar ayuda enormemente en
performance y hay sistemas que son muy criticos en este punto, por lo cual
quizas una desnormalizacion buena pueda ser interesante.




Maxi

Buenos Aires - Argentina
Desarrollador .NET 3 Estrellas
Microsoft User Group (MUG)
Mail: Maxi_accotto[arroba]speedy.com.ar

Msn Messenger:

"Eric Garza" escribió en el mensaje
news:

Hola Maxi:

1.- Esa tabla no está normalizada, la columna "saldo" es completamente
innecesaria y sólo se usa en la capa de presentación (Es una cuenta T de
Contabilidad).
2.- El tener una columna saldo asume que nadie va a insertar un registro
con
una fecha anterior e invalidar todos los saldos posteriores.
Se presentan problemas de integridad de información; si no, ¿por qué
necesitaría hacer un UPDATE como ese?
3.- Las soluciones para realizar semejante UPDATE no escalan
adecuadamente;
con tablas grandes, un cursor tal vez sea más apropiado que una solución
de
O(n^2) como la que le propuse.

Pero en fin, cada cabeza es un mundo, como decimos por acá.
¿Cuáles son tus razones para usar un diseño como ese?

Saludos,
Eric Garza
AMIGE

"MAXI" wrote in message
news:

Eric, creo que la mejor forma es justamente hacerlo en la BDD mientras

esto

no haga cursores claro esta!!

En que te basas para decir que no es para la BDD? porque yo creo que
justamente este tipo de cosas dentro de un SP son lo ideal