Database design: Aggregate vs Store

In a stock control system, which records the following entities in the database (this is over simplified of course):

• Items (for which the stock needs to be controlled)
• Stock movements:
  • Input movements (they add up to certain item stock)
  • Output movements (they substract from certain item stock)

Which is the best strategy and why:

• Store the current quantity for each item and update it every time a movement is recorded.
• Don't store the current quantity in each item and calculate it every time is needed as item.current_qty = sum(item.input_movements.qty) - sum(item.output_movements.qty (this is no particular language, it's just pseudo code)

Take into account that, being a stock control system, the current quantity for each item is used a lot.

Note: this question is similar to this other, but this one is especially about data that can be aggregated.

Option B (calculate) is the Normalized one.
I have done it that way in an ERP that I made for a client, using Access as the front-end, and SQL Server as the back-end. To date there are about 250.000 movements and it's still snappy.

I think it depends a bit on your volumes and which db engine you are using. If it is Access for example, there are no triggers and I would not rely on the front end logic. On SQL Server you could denormalize and have the quantity on hand recalculated at every movement, plus eventually make recalcs when problems arise.

A nice way to go for me: see the excellent analysis of the question by Allen Browne available here.

Addition (Oct 2024)
Depending on your goals, stock INPUTS and OUTPUTS might not be the only moves you want to track!
In an ERP style development, you might also need SUPPLIER BACKORDERS (SBO), CLIENT BACKORDERS (CBO) in order to provide the business with a clear view of the situation.