4 ms·

I feel like this is one of those cases where people take a mantra too seriously. Storing values that could otherwise be derived results in complexity and discr

I feel like this is one of those cases where people take a mantra too seriously. Storing values that could otherwise be derived results in complexity and discrepancy. This may lead people to the conclusion that all values which can be derived should be derived, but in the case of a receipt/invoice, this is not the right call. Discretion must be applied.

joshu 3y ago
your comment doesn't provide when to decide one way or the other, which makes it more warning and less useful. when the data is stuff that could be paperwork - you get a copy, i get a copy - it should not be the case that one side gets to unilaterally decide if the data is deleted or modified.
- shortcake27 3y ago
  I am in agreement with you. I’m just saying that developers need to apply discretion rather than following arbitrary “rules” or “patterns”. When to store or derive depends on the use case, of which are infinite.
- mrighele 3y ago
  I think it is not difficult to decide: sometimes you want to reference an entity with its current state, some other times you mean with the properties that it has at a specific point in time. For example if I don't pay yearly tax on my car I will receive a fine. The fine may arrive one or two year later, but it should be sent to me even if I sold the car meanwhile, because what matters is that I was the owner at the time. On the other side, the fine should be sent to my current address, not the one I had when I forgot to pay. There a number of ways to handle this. The simplest is to make a copy of the data, but you can also decide to keep all the historical data and reference the state during a certain time interval. Both can be valid choices, depending on the context, frequency of change, number of references....
squeaky-clean 3y ago
I think the biggest deciding factor in this particular situation is what the article says in the sub heading. 'A “Receipt” is immutable'. You don't care about the consistency guarantees of normalization. You don't care about being able to re-derive it with new logic or additional features. And in all likelihood the storage savings from not storing the final generated output is going to be miniscule. If some data is meant to be truly immutable, and storing it separately won't impact your storage costs, store it separately. Because otherwise that immutability needs to be somewhere else in the system. If you normalize your data and dynamically derive receipts, your logic needs to include all receipt logic you have ever used, cordoned by timerange. Was the price of a large Pizza changed in 2018? Your receipt logic and data has to reflect that forever. Did you allow stacking coupons but in March 2017 you started limiting it to 1 coupon per customer? Your receipt logic and data has to reflect that forever. Did you have a week where prices were rounding in the wrong direction when a certain coupon code was used? That has to be in your receipt handling forever. There's just so much additional effort, so much potential to go wrong, and so little to gain.

joshu 3y ago

your comment doesn't provide when to decide one way or the other, which makes it more warning and less useful. when the data is stuff that could be paperwork - you get a copy, i get a copy - it should not be the case that one side gets to unilaterally decide if the data is deleted or modified.

shortcake27 3y ago
I am in agreement with you. I’m just saying that developers need to apply discretion rather than following arbitrary “rules” or “patterns”. When to store or derive depends on the use case, of which are infinite.
mrighele 3y ago
I think it is not difficult to decide: sometimes you want to reference an entity with its current state, some other times you mean with the properties that it has at a specific point in time. For example if I don't pay yearly tax on my car I will receive a fine. The fine may arrive one or two year later, but it should be sent to me even if I sold the car meanwhile, because what matters is that I was the owner at the time. On the other side, the fine should be sent to my current address, not the one I had when I forgot to pay. There a number of ways to handle this. The simplest is to make a copy of the data, but you can also decide to keep all the historical data and reference the state during a certain time interval. Both can be valid choices, depending on the context, frequency of change, number of references....

squeaky-clean 3y ago

I think the biggest deciding factor in this particular situation is what the article says in the sub heading. 'A “Receipt” is immutable'. You don't care about the consistency guarantees of normalization. You don't care about being able to re-derive it with new logic or additional features. And in all likelihood the storage savings from not storing the final generated output is going to be miniscule. If some data is meant to be truly immutable, and storing it separately won't impact your storage costs, store it separately. Because otherwise that immutability needs to be somewhere else in the system. If you normalize your data and dynamically derive receipts, your logic needs to include all receipt logic you have ever used, cordoned by timerange. Was the price of a large Pizza changed in 2018? Your receipt logic and data has to reflect that forever. Did you allow stacking coupons but in March 2017 you started limiting it to 1 coupon per customer? Your receipt logic and data has to reflect that forever. Did you have a week where prices were rounding in the wrong direction when a certain coupon code was used? That has to be in your receipt handling forever. There's just so much additional effort, so much potential to go wrong, and so little to gain.