Storage of "received" values ​​compared to their calculation when retrieving

Question

If you have values ​​that depend only on one or several other fields of +/- constants (for example, retail price and discount price), is it better to store these values ​​or calculate them on the fly when receiving data

Answer 1

I agree with Tomislav - try to avoid redundancy, because you can get data about several tables that do not agree with each other. This makes updates more painful.

There are exceptions that, however, deserve consideration that are not related to database performance.

• When it is painful to calculate a value (for example, some complex mathematical function), then it makes sense to store it (you could think of a column as "the last calculated value").
• You may have inputs that change over time, for example. the fee is based on the interest rate, but the interest rate is stored as one value in the configuration table. You might want to charge a fee because historical fees will only be calculated at the current rate. Alternatively, you can also maintain speed over time to get around this problem.
• If the derived value can be overridden by user input or some other process, then again it makes sense to store. Alternatively, you can simulate this using the two “CALCULATION” and “FRONT” states so that you only keep the value in the last state.

Answer 2

By default, redundant information is not saved: the third normal form is usually a reasonable initial goal. Reservation is introduced when a “reasonably good” reason appears, such as a “reasonably large” performance that you get when you have to calculate a derived value and the calculation is intense.

Obviously, “good enough” and “big enough” are qualifiers that only mean something in this context. For what it's worth, a retail / discount calculation is considered too cheap and easy to use to guarantee the introduction of an excess column in most (obviously not all) cases.