Calcular saldos con SQL

roman · #1 16-05-2005

Cita:

Empezado por mazinger

Supongo que calcular el saldo al mostrar los registros es igual de complicado que hacerlo e irlo almacenando en un campo. En cualquier caso gracias.

No veo por qué ha de ser complicado:

Código Delphi [-]Query.SQL.Text := 'select haber, debe from cuenta';
Query.Open;

Saldo := 0;
while not Query.EoF do
begin
  {
    Aquí muestras o usas Query['haber'], Query['debe'], Saldo
  }
  
  // Y calculas el siguiente Saldo
  Saldo := Query['haber'] - Query['debe'] + Saldo;
end;

Y esto suponeindo que realmente quieres mostrar los saldos parciales porque si lo que quieres es obtener el saldo final entonces se obtiene de un sólo golpe:

Código SQL [-]select sum(haber-debe) from cuenta

// Saludos

axelbb · #2 17-05-2005

Si, está claro lo que necesitas hacer.

Respecto al comentario sobre triggers de Epachsoft, hay bastante de verdad si esa tabla se maneja de manera poco ortodoxa, ordenada y documentada. Aún así se definen los triggers para caso de updates o de inserts, o de borrados, bien pensados para cada caso, y se ejecutarán siempre, sin posibilidad de olvidarse de hacer algo como actualizar el saldo. Eso garantiza la integridad de los datos, porque la regla se ejecuta aunque te olvides que existía, o aunque quieras guardar un saldo incorrecto. Y calcular el saldo nuevo ante cada operación... creo que es una regla de integridad fundamental en tu caso (ni pensemos si quedara mal en algún sitio y siguieras calculando desde allí). Aclaremos además que un trigger puede desactivarse si se desea que en una operación particular no se ejecute. Las dificultades que plantea Epachsoft pueden ser un precio adecuado a cambio de otras ventajas, que tendrás que sopesar. Personalmente, cuando una regla para una tabla es irrevocable, como que el saldo debe ser congruente con los debes y haberes... ni lo pienso, esa regla es parte de la tabla y el trigger (bien diseñado) me la garantiza. Pero es mi criterio personal.

Respecto al código de Roman:
Query.SQL.Text := 'select haber, debe from cuenta';
está correcto, para trabajar en tu programa los datos, sólo que traes al cliente todos los registros de la tabla, y si es grande... pobre red (a menos que hablemos de tablas "de escritorio" y el BDE, en cuyo caso ni hablemos de triggers). Además, me parece que calcula un saldo mucho más rápidamente un motor en un servidor que un programa Delphi en un cliente recorriendo secuencialmente los registros de un Query, habría que probar.

Insisto que es mejor solución no guardar el saldo, a la 2da. sentencia de cálculo de Roman le agregaría un "where fecha<TuFecha1" (supongo que hay un campo para la fecha del registro, obvio), para que el servidor te retorne el cálculo de SALDO HASTA el momento que necesites el detalle, y luego sí el
'select haber, debe from cuenta where fecha>=TuFecha1 and fecha <=TuFecha2'
para mostrar, listar, operar con los datos en detalle, pero solamente los datos que te hagan falta estrictamente. Por ejemplo, movimientos de banco entre fecha1 y fecha2. Calculas el saldo hasta fecha1 (sin ese día) y traes los registros de movimientos para ese intervalo de fechas, y ahí sí, recalculas el saldo en tu programa con el método que te pasó Roman y lo listas.

Si optas por la solución de Epachsoft y seguir con el campo saldo en tu tabla (a veces no dan ganas de romper lo que ya se hizo, no?

), es buena su idea también del almacenado. Allí, pueden serte útiles las sentencias tipo "select last 1 saldo group by saldo" (a mí no me funciona en FireBird

) o "select first 1 saldo group by saldo desc" (esa sí anda

) que obtienen ambas el último saldo, o las que se te ocurran dentro del SQL soportado por tu servidor. Sólo que ante cada cambio (insert, update o delete) deberás tener un almacenado específico (calcular para el registro agregado, o recalcular para luego del borrado o modificado, si se cambió debe o haber) que no deberás olvidarte nunca de ejecutar (a menos, claro, que para hacer cada una de esas operaciones acudas a ese almacenado, directamente, pasándole parámetros con los datos (fecha, debe, haber...), para que los guarde y de paso recalcule el saldo como corresponde. Eso sí, si la base de datos se reparte en aplicaciones que hagan otros programadores, que lleguen a hacerte solamente el Insert y se olviden del almacenado...

No pensemos en eso.

Soy medio nuevo en esto, pero es como lo plantearía (yo, sin campo saldo)

Suerte y saludos.

roman · #3 17-05-2005

Vamos a ver, no sé si voy a rebatir o a apoyar lo que dice axelbb.

Desde luego que la sentencia "select haber, debe from cuenta" muy posiblemente va complementada por una condición WHERE pero el punto es:

Si necesita mostrar los saldos parciales (en un rango de fecha u otra condición) entonces de cualquier forma tendrá que bajar todos esos registros al cliente por lo que el tiempo excedente del cálculo del saldo parcial es imperceptible (no estamos hablando de una operación compleja sino de una simple suma acumulativa).

Y si sólo requiere mostrar el saldo total, entonces no hay que molestarse siquiera en calcular los saldos parciales ya que estos se cancelan y sólo queda:

saldo total = haber total - debe total + saldo inicial

por lo que una sólo consulta basta.

No veo ninguna necesidad de triggers, bien o mal planteados. La congruencia entre el saldo y los haberes y deberes se dará al momento de acceder a los datos puesto que no veo ninguna necesidad de almacenar los saldos en la base.

// Saludos

axelbb · #4 17-05-2005

Parece que escribí muy confuso

, me distraje en el debate.

A) De acuerdo con Roman en que no hace falta campo saldo. Pero NO es necesario bajar todos los registros al cliente:

select sum(debe-haber) as saldo from cuenta where fecha < Fecha1

se ejecuta EN EL SERVIDOR y retorna solamente un campito llamado saldo con una sola fila con el saldo a esa fecha. Como un saldo se arrastra día a día, debe calcularse (debe-haber) desde el primer registro. NO HAY un rango para esto, no hay saldos parciales, hay un límite inferior (fecha hasta). No veo que sea necesario bajar todo al cliente, ¿estoy en lo correcto o sigo sin entender tu enfoque?.

Luego:

select debe,haber,fecha,nota_explicativa... from cuenta where fecha >= Fecha1 and fecha <= Fecha2 (que puede ser Now, fin de año...)

que me trae el DETALLE de movimientos en el RANGO necesario (ahora sí).

Resultado, Banco desde el 15/5 hasta hoy, por ejemplo:

Fecha Detalle movimiento Débitos Créditos Saldo
==========================================
Saldo anterior 1000.00 <-Primer select
15/5 Depósito valores 20.00 1020.00
15/5 Cheque 11122 60.00 960.00
16/5 Cheque 11123 100.00 860.00
17/5 Nuevo Saldo 860.00
==========================================

Los datos en verde surgen del segundo select y los saldos de la operación que los haga el programa calculando, partiendo del saldo inicial.

B) A veces, hemos planteado mal el problema en un principio, hemos desarrollado mucho alrededor de ese error y preferimos mantenerlo así, o hay alguna razón más que fundamenta el uso del campo SALDO. Ahí, como alternativa, sostengo el uso de triggers para asegurar la integridad. El pide una sentencia para obtener saldo anterior, y le pasé una posibilidad (sinceramente, soy nuevo pero quiero ayudar como ustedes lo hicieron antes conmigo) con

select last 1 saldo from cuenta order by id_movimiento o
select first 1 saldo from cuenta order by id_movimiento desc

He visto motores donde hay funciones que devuelven un campo del último registro, estilo Last_row_value('SALDO') (el nombre lo acabo de inventar), pero no sé si todos tienen algo así.

Eso responde una fila, un campo, con el último saldo, siempre que identifique cada operación con su id, cosa que me parece muy conveniente (equivoqué algo en el anterior mensaje

con el group by).

Pero sí, 1000% de acuerdo con vos, Roman, que la A) es mejor alternativa, no hay posible incongruencia

.

Saludos, y disculpen mi confusa redacción. Creo que al final no ayudé nada, una pregunta simple se hizo una larguísima discusión. Mazinger salió corriendo y encontró la solución anoche en su libro de SQL...

roman · #5 17-05-2005

Cita:

Empezado por axelbb

A) De acuerdo con Roman en que no hace falta campo saldo. Pero NO es necesario bajar todos los registros al cliente:

select sum(debe-haber) as saldo from cuenta where fecha < Fecha1

se ejecuta EN EL SERVIDOR y retorna solamente un campito llamado saldo con una sola fila con el saldo a esa fecha. Como un saldo se arrastra día a día, debe calcularse (debe-haber) desde el primer registro. NO HAY un rango para esto, no hay saldos parciales, hay un límite inferior (fecha hasta). No veo que sea necesario bajar todo al cliente, ¿estoy en lo correcto o sigo sin entender tu enfoque?.

Exactamente, no es necesario bajar todos los registros a menos que desee mostrar al usuario los saldos parciales.

A lo mejor digo una tontería pero no sé si mazinger tiene claro que para mostrar el saldo final no es necesario ir calculando los saldos parciales.

// Saludos

axelbb · #6 17-05-2005

Ah, ahora entendí. "La información está buscando desesperadamente mi cerebro"

mazinger · #7 17-05-2005

Pues no, no salí corriendo

Está interesante la discusión, pero tengo que apuntar que sí que necesito calcular el saldo parcial para cada registro, al estilo de un extracto bancario, ya que lo utilizo para comparar en cada apunte si me coincide el saldo que yo tengo con el saldo que calcula el banco. Además el orden de introducción de los apuntes no es necesariamente ordenado, ya que a veces puedo insertar un registro antes que otros que ya tenían calculado su correspondiente saldo, con lo cual me tocar recalcular los posteriores.
Sigo dándole vueltas al tema, pero aún no he encontrado una solución satisfactoria.

Gracias por vuestro interes