hypothetically, if i were with a system that keeps track of products and order information across multiple tables (orders, order_items, product)
orders
id INT(11)
shipping_name VARCHAR(255)
shipping_street VARCHAR(255)
shipping_city VARCHAR(255)
[etc]
order_details
id INT(11)
order_id INT(11)
product_id INT(11)
products
id INT(11)
name VARCHAR(255)
description VARCHAR(255)
price DECIMAL(8,2)
structure is very simple order
has multiple order_items
, order_items
has one product
.
the problem is that when someone edits a product, those edits modify the data of previous orders. if an employee were to go back and look at that information later on, they may not have the same information that the customer received at the time the order was placed.
What would be best practice? should i add a 'display_item' field to the products table, and on edit/delete set display to 0 and add edited product as new row? should i duplicate the name, description, and price in order_details?
I think this is one of those cases where database normalization "breaks".
Some possible solutions:
Proposal for option 1
Create a copy of the products
table and create a relation (one-to-one) to the order_details
table for each order and order detail.
Proposal for option 2
Split the products
table in two: product_general_info
and product_attributes
. Product general info is meant to be stable through time (a product's general info will not change), as any modification to the data in this table will propagate to the whole orders set. Product attributes must have a date
or timestamp
value to define when the attributes changed. Then you can query the database and return the last record that is before or on the order date.
The technical post webpages of this site follow the CC BY-SA 4.0 protocol. If you need to reprint, please indicate the site URL or the original address.Any question please contact:yoyou2525@163.com.