Just wondering what the optimal design pattern would be for the following data I'm trying to model.
I have a table that stores information for Orders that have been placed by customers.
Orders can be either Invoiced or Opened.
Currently, the table stores data about the total Order information (so...invoiced+open).
The Invoiced and Open information has to be calculated in code and then Updated per row. Technically speaking, this information can just exist in memory of the app after the calculations. But..I figure...storage is cheap and it'll probably be useful to store this data in the table for later on.
However, I feel like it's kinda awkward and can lead to large rows.
I.e I'd have
Are there any better ways to do this?