Design advice for vertical list calculations

Question

I'm extending a product management life cycle sharpoint 365 site,
With purchase orders, magazine store, production targets (date based) and sold dates.
So that in our production environment we can see how much is stored, how much can be sold, and what we need to buy in etc.
The thing i'm a bit troubled about that sharepoint lists are not Excel, but this has to be done with Sharepoint lists.
They prefer not to have edits directly in the aspX code, but editing workflows in Sharepoint designer is OK
In excel one could easily add a cell formula with the content of Sum the value in the row left of me and add it to the value of myself one row earlier (like B2 contained  = A2+B1 ); and then copy that formula to the whole B column
The nice thing with Excel is that when you change some value in A, like A2 = 10 and and later A5=10 then B7 would be 20
Changing later a value like A3 =4 would recalculate quickly and re- totals the B column.
Sharepoint Lists, calculated fields work only horizontally, so to do some vertical actions one needs a workflow, and do some lookup based upon (calculated previous) ID field, ea ID -1. Or stepp through to All ID's till current. What borders me a bit, is that
my list will grow large at some point. So stepping through all ID's to sum them till current Item seams 'slow' to me, on the other hand if i only check the previous version then the whole column (B) wouldnt be recalculated, if someone changed an older entry.
Extremly simplified i have a single list with the columns below (where stored act as my B column).
bought | stored | sold
0 | 5 | 0
2 | 5 | 0  (raw products need to be manufactured before stored so they're added 1 by 1 later).
0 | 6 | 0
0 | 7 | 0
0 | 4 | 3 (but when sold we can subtract directly from storage)
Ofcourse i need some horizontal calculations because i need to track as well if there has been bought enough for production. But i wonder what would be Wise to do, base thing on current ID and ID minus 1, or to walk through all items by work flow (recalculate
whole list), or like with changes; recalculate from current changed till the end  (not sure how to detect end yet.. but well something like that).
I just wonder what would be wise here, and the best direction for this.
The table i showed is a  extreme simplified, in fact also some other tables and workflows will be the feeders of the data.
Its just that the whole thing makes me a bit worry and wonder what would be best, and maybe i oversee something maybe there are other ways for vertical calculations over lists.

Answer 1

After lots of thinking, and seeing how slow office 365 SharePoint reacted upon my list workflows.
I've decided to use a "site variables list", in which I store variables as rows and their value in a columns.
And I refer to them by ID (or one could use another indexed unique value).
It's maybe not an exact calculation of the whole thing (build around several lists) but everything is a lot faster then stepping trough each item in a huge list. And it also allows for a bit more easy tweaking of these "vertical" calculations.
If for some reason those calculations would need adjustments (by change of management definitions), I have easy access to those variables to adjust them.
On a side note, when I use those variables, it turned out it worked a bit better to create in the workflow local variables, then do the calculation, and put it in the right table you want those numbers to appear in. As compared to directly referring to the
total. It takes just 5 sec or so to update. With this method size of the lists have no almost no impact on the speed of the workflow now.