How to correctly enter the warehouse and finance (business logic)?

Question

MySQL

Good afternoon. I want advice on designing and keeping records of finances and a warehouse in an online store.
Searched for information on the Internet. I found a good article on Habré .
Exactly as I planned to do the same

But for fun, I decided to complicate the implementation in case of a large number of operations - the account balance at the beginning of each month is stored in Balance instances, when each operation is recorded, the balances at the beginning of the next month (and later, if any) are recalculated. But to calculate the balance for the current date, you only need to take the balance at the beginning of the month and calculate the turnover on the operations of the current month. This approach will not cause performance issues over time.

Load - 1000 orders per week, about 5000 operations per week.
For such a load, is it enough to store the total amount / warehouse monthly, maybe every week is better?
What if I found a mistake in finances and edited a record a month ago?
Will there be an analogy with the warehouse of goods?
According to finances, there was also an idea to keep the archive on the date of the operation.
Pros:
- no need to recalculate anything.
- only 1-2 iterations
Disadvantages:
- when correcting an operation from the archive (7,14, 30 or more days later) hard recalculation?
Who has any experience in building such systems and other algorithms for calculating finances and current flow?
PS It would be interesting to see the organization of such a service as zenmoney.

Answer 1

For such a load, is it enough to store monthly, maybe every week is better?

Who to keep?
This number of objects is tiny.

Who has any experience in building such systems and other algorithms for calculating finances and current flow?

Store the computed state. On request, on schedule and before certain actions, recalculate by history.

Answer 2

What you write about is implemented in 1C Enterprise.
In version 7, these are really separate database files, starting with RA* (records for each operation) and RG* subtotals calculated every month (or more often, depending on what system settings are). They are a common DBF format - there are a bunch of viewers that will show how it works inside.
In both version 7 and version 8, this can be seen from the inside.
Read forums on 1C 7 - there were many articles on how it works and how it can be improved.
In the 8th version, 1C has advanced very quickly and far - articles on the analysis of its device are not yet in time.
In terms of 1C, this is called the "Accumulation Register".