I get your point but I am not quite sure about that example. If you have the receipts linked to a certain version of a product (via an unique ID) in a give rece

I get your point but I am not quite sure about that example. If you have the receipts linked to a certain version of a product (via an unique ID) in a give receipt, then you can easily derive these figures via a separate item code. A large pizza could be PIZZA_L and have revision IDs 1, 2, 3... I assume that's what you mean by product/product revision, you don't need a separate table for it per se (as any number of fields for a given model may need to be changed, which makes the classification of what field belongs where much harder than having one model and a shared identifier). You can always prepare a bad report, I don't think that this schema or that schema will solve all problems, but having a schema which keeps a complete history of changes to its data should be better than one that just lets you run an UPDATE query to actually mess the price history up.