We're not the Relational Cops. We only suggest and advise. You get
to do whatever you want to do in your own applications.
You've named a special case and it may require special treatment. You
could have a new and separate table named for its purpose that stores
the snapshot value with an associated date in that table. Note that,
in almost all cases, it is possible and preferable to calculate the
value when required.
Probably the best way to deal with situations in which the value of a
thing such as *price* or *cost* changes over time is to track the
dates of the changes and the new value at each change. If you want to
present the result that was true at a given time it is only necessary
to calculate the result based on what the value of the variable that
was true at the target time. That makes it unnecessary to store data
that is sure to become invalid.
Another way to go about the above is store the actual value of a
variable that changes over time rather than a pointer to it. That
breaks a different Relational rule but at least makes the basis for
the calculation visible.
Another situation might be something like a *posting* table; i.e.
Quarterly Balances. As the books are closed for one Quarter the new
balance is written to this account's record in that table for this
quarter. Going forward, the Beginning Balance for the new quarter is
taken from that table and entered in the account. All new
transactions are summed with that number to arrive at the Current
Balance.
HTH
