2

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.

Community
  • 1
  • 1
mmutilva
  • 18,688
  • 22
  • 59
  • 82
  • Either could be valid situationally, but also there is always the option of doing both - record movements in a separate table availble for auditing and detailed inspection, record overall state in an aggregated primary table. – annakata Dec 22 '10 at 15:40

1 Answers1

3

Option B 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.

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

iDevlop
  • 24,841
  • 11
  • 90
  • 149