Order storage strategy?

Question

MySQL

Colleagues, let's breed a holivar.
Doesn't give me peace, the question.
Question related to the storage strategy of orders.
The sooner I solve it the better, and maybe someone will come in handy.
Get to the point.
Entities
---------------
Product
Order
Customer
---------------
Here everything is as simple as possible.

But we do understand that after a person has ordered something, the price can always change.
The main message of the question is how to store history?
Need to create another table with products, where they will be recorded?
Or just save the name and price, somewhere in the History Products Orders.
I perfectly understand that there should be another table where the purchased goods will be recorded, but what the hell should I call it, so that it would at least sound logical.
Thank you!

Answer 1

It is hardly possible to breed a hollivar here. The order must have a time stamp and the price change record must have a time stamp, respectively, the price for the order must be equal to the latest price setting record with a time less than the order time.
That is, the price should not be in the product (although you can leave it there to get the current price at the moment), but in the prices table (timestamp, product_id, price) indexed by the first two columns.

Answer 2

IMHO (in any case, I do this):
there is an orders table, with which ordered_items is connected, which in turn is a duplicate of the goods table, except for the qty field - quantity. And in the admin panel, you can open an order, view products, delete if they refused, etc...