How to design a relational database that stores snapshots of tables?

I have the following tables:

• products
• companies
• purchases (has one company, has many products)

I need to be able to create invoices based on the above 3 tables. The problem I'm facing is that since the products are editable one could change the price, thus making the invoice invalid: the price of the product is no longer the same price when the purchase happened

I thought about storing the total price on the purchase table (this would allow me to get a total price of the purchase), but I need to display more granular data on the invoice, on a per product basis.

The same problem happens with linking companies to purchases. If I need to store the invoices on a table, the invoice will always reflect the most current data, which is not ideal. Editing products would change every stored invoice that relates to a particular product that was edited.

Yet a third problem arises when it comes to making reports based on multiple measures that are all stored in different tables. I can never make an accurate report for a point in time if I keep updating related tables.

Really what I need is "time travel" I think. I've considered a few options:

• Create a "snapshot" table for each table, with the same schema etc. These snapshot tables would be then linked to the tables I need to use for reporting, invoicing and such.
• The above but using the same tables. Any row with a parent_id would be a snapshot.
• When editing products, create new products instead, and keep the original untouched.

This last one seems the worst solution. What is this problem called that I'm facing in general terms? How can I go about it?

**by "linking" I mean setting up relationships using foreign keys.