Fórum Como trabalhar com Saldo Anterior. #41268

E ai,

Vc pode criar uma view com todos os saldos, evitando assim ter que criar tabelas.

Ex:

Create View Saldos(Data, Saldo) as
Select data, sum(valor) from caixa
Group by Data

Assim no teu sistema vc localiza a data e pega o saldo.

Ex:
Select * from Saldos Where data = ultimadatalancada.


Abraços.

É importante verificar que esta questão está bastante relacionada com a estratégia, análise de sistemas. É claro que se você precisar mostrar o saldo para o usuário mostrando por data, há um trabalho adicional ao banco de dados para remontar os saldos se você não usar tabelas, a aplicação poderá ficar lenta por causa desta operação e de fato é uma questão complicada.
Complicado mesmo é você considerar que sua aplicação é multiusuário e que diversos usuários podem estar realizando lançamentos ao mesmo tempo em uma mesma conta, o problema real é o saldo atual consistente, se você usar tabelas para armazenar o saldo atual terá que se lembrar fazer seus inserts e updates de modo a manter a consistencia de valores. Para real consistência é mais fácil remontar o lançamentos calculando o saldo mas note que há muito mais processamento assim do que apenas consultar uma tabela. Lembre-se que terá de fato que para muitas situações guardar em tabelas próprias o saldo, por exemplo referente ao fechamento de balanço por ano, é inviável remontar o saldo atrávés de todos os lançamentos, podem haver milhões, e o sistema precisa estar com uma ´fotografia pronta´ dos balanços a qualquer tempo.
Para sistemas muito grandes, a melhor estratégia é usar pelo menos 3 camadas, o banco, um aplicativo servidor que somente ele acessa o banco e têm controle total das operações de saldo, e a camada cliente que acessa o aplicativo servidor, assim são as Redes Bancárias, aplicativos cliente dos usuários não têm acesso ao banco de dados.
Minha sugestão é a seguinte, verifique o volume de lançamentos que seu programa deverá suportar. Se necessariamente você precisar mostrar saldos por data e estes forem muitos, para acesso mais rápido será interessante o uso de tabelas, mas neste caso tenha cuidado para mantê-las consistentes com os saldo corretos, dependendo você poderá usar views, lembre-se de como você projetou a realização de estornos e se realiza operações de correção de um lançamento sem necessariamente realizar uma operação de estorno no banco (não recomendável para sistemas que merecem auditoria).
Em princípio um sistema de contas deve registrar tudo o digitado mesmo que tenha sido digitado errado, então deve-se registrar outro lançamento que é o estorno para corrigir o erro, isto fica registrado (e deve pois precisa constar no diário razão assim para não haver fraudes), num desenvolvimento assim o uso de views acabará sendo de bastante uso; o uso de tabelas pode tornar o sistema mais rápido já que pode ser atualizada on demand mas por outro lado depende de maior esforço de programação e cuidados com a questão das consistências também. Você só precisará tornar seu sistema mais robusto por tabelas se for voltado para muitos usuários usando extratos das contas ao mesmo tempo, normalmente até 20 não há problemas para degradar muito a velocidade.
Note que muitas operações de consolidação são demoradas pelo fato de remontarem tudo olhando lançamento a lançamento, parecidas com o seu caso de saldo anterior, muitas operações merecem grande cuidado. Acho que realmente é um problema que você deverá estudar, medir e dicidir conforme sua análise.