Derived account balance vs stored account balance for a simple bank account?

Question

So, its like our normal bank accounts where we have a lot of transactions which result in inflow or outflow of money. The account balance can always be derived by simply sum

Answer 1

This is fairly subjective. The things I'd suggest taking into account are:

1. How many accounts are there, currently?
2. How many accounts do you expect to have, in the future?
3. How much value do you place upon scalability?
4. How difficult is it to update your database and code to track the balance as its own field?
5. Are there more immediate development concerns that must be attended to?

In terms of the merits of the two approaches proposed, summing the transaction values on-demand is likely to be the easier/quicker to implement approach.

However, it won't scale as well as maintaining the current account balance as a field in the database and updating it as you go. And it increases your overall transaction processing time somewhat, as each transaction needs to run a query to compute the current account balance before it can proceed. In practice those may be small concerns unless you have a very large number of accounts/transactions or expect to in the very near future.

The downside of the second approach is that it's probably going to take more development time/effort to set up initially, and may require that you give some thought to how you synchronize transactions within an account to ensure that each one sees and updates the balance accurately at all times.

So it mostly comes down to what the project's needs are, where development time is best spent at the moment, and whether it's worth future-proofing the solution now as opposed to implementing the second approach later on, when performance and scalability become real, rather than theoretical, problems.