Calcular saldos con SQL

[axelbb]

Si tenés la posibilidad en tu motor, podés probar de hacer un trigger (after update). El trigger se dispara sólo, cuando cambiás el contenido de cada registro automáticamente hace un debe*haber y lo guarda en el saldo. Como es automático por cada modificación, sin hacer nada el motor solito te mantiene el campo actualizado. No sé si entendí bien el problema. Si no, tendrás que preguntarle a alguien que sepa algo del tema .

Saludos.

[axelbb]

Sí, entendí mal. No es que en cada registro tenés un resumen de cada banco, sino que acumula un saldo de un mismo banco...
En primer lugar... ¿Te resulta indispensable hacer eso? En general el saldo debería surgir de un cálculo en el momento de la consulta. Si el temor es que sea muy lento cuando tengas muchos registros, de todos modos podés hacer un trigger que tome el saldo del último registro y sume tus valores de debe y haber.
¿Cómo sería? dejame ver que recuerdo haber hecho algo parecido alguna vez. Busco y te lo paso, si es que ahora sí entendí.

[Epachsoft]

Los triggers son increiblemente comodos, pero altamente peligrosos, no son faciles de seguir en caso de "debug", y pierdes control absoluto de la accion, asi que cualquier update que se realice sobre la tabla, sin importar la ubicacion o el proposito se vera reflejado.

Yo no lo consideraria algo apropiado para este tipo de operaciones. Si estas usando MSSQL 2000, te recomendaria una funcion, que simplemente retorne el monto del mes anterior, para el registro actual.

Si tas usando otra db puedes usar puro sql, puedes crear una vista y agregarla en el From del update, esta vista mostraria todos los registros menos el ultimo, etc.

De cualquier manera PLSQL es mas completo que TSQL por lo que debe de haber un equivalente de funcion.

Muchas opciones, suerte con eso.

GO DELPHI!

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

Seria algo como esto:

	 Debe	Haber	 Saldo	Saldo anterior		 Haber - Debe + Saldo anterior
		 30	 30	   0			 30 - 0 + 0 = 30
	  20		  10	   30			0 - 20 + 30 = 10
		 25	 35	  10			25 - 0 + 10 = 35
 
......

Traducido a SQL

UPDATE Cuenta SET Saldo = Haber - Debe + [SaldoAnt]

Donde Saldo anterior hace referencia al saldo del registro anterior, pero no sé como se hace eso.

[roman]

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]

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]

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