订单数据冗余答案

【问题标题】：Data redundancy for order订单数据冗余
【发布时间】：2019-03-27 08:52:37
【问题描述】：

表格order_detail：

order_no | product_id

表product_detail：

prod_id |产品名称 |产品尺寸 | prod_type

order_detail .product_id  references to product_detail.prod_id

我听说数据冗余是个坏主意，所以我内部连接表以显示完整的订单详细信息。但是问题是product_detail里面的数据可以被管理员编辑或删除，这意味着当我内部加入表时，它可能会返回null。我是否应该在order_detail 中存储类似 JSON 示例：{size:23,type:MZ} 以避免数据“丢失”？

【问题讨论】：

在order_detail上使用LEFT JOIN
看起来管理员做得不好。
您应该确保数据库不允许部分删除数据，或修改影响其他部分的数据。如果您下订单并且有人更改了产品，那么这会更改引用数据的每个订单，这可能并不好。减少冗余不能以牺牲数据完整性为代价。
如果您的admin（只是您的程序 IMO 的用户）可以删除产品详细信息，即使该产品有/有订单，那么您的业务逻辑 (BL) 有问题.那个BL做数据loss。 IMO，您应该与您的团队讨论尽快更改它。
关于“我听说数据冗余是个坏主意”：“数据冗余”没有什么特别的含义。不要担心谣言，教育自己。是时候阅读已出版的关于信息建模、关系模型和数据库设计的学术教科书了。（记录和使用设计的语言和工具手册不是这样的教科书。）（维基文章或网络帖子也不是。）数十种已出版的学术信息建模和数据库设计教科书以 pdf 格式在线免费提供。 stanford.edu 有免费的在线课程。（但在 SO 之外寻求资源是题外话。）

标签： mysql sql database-design

【解决方案1】：

您需要分解表结构。

必须在 order_detail 表中以 JSON 格式存储数据会损害数据库中的 normalization（这是不可取的）。

将产品属性作为单独的实体。

产品详情

标识 |姓名 | some_other_descriptive_columns |删除_at

产品类型：

标识 |输入

产品尺寸：

标识 |尺寸

Product_type_mapping：（表示产品与其类型之间的多对多关系的数据透视表）

标识 |产品编号 | product_type_id |删除_at

Product_size_mapping：（表示产品与其尺寸之间的多对多关系的数据透视表）

标识 |产品编号 | product_size_id |删除_at

您可能已经注意到，我们有一个名为deleted_at 的附加列，其数据类型将是timestamp，在上面显示的所有表格中默认为nullable。
当管理员编辑（也可能是删除某些尺寸或类型）或删除产品时，我们所做的只是在deleted_at 列中输入时间戳。换句话说，我们执行软删除。
因此，当管理员对产品数据集进行操作时，获取所有 deleted_at 列为 NULL 的详细信息。在进行内部连接以获取订单详细信息时，即使管理员在下订单几天后删除产品，它也不会妨碍丢失任何数据的过程，因为我们将获取所有详细信息，无论我们在我们的 @ 中有什么987654328@专栏。

【讨论】：

【解决方案2】：

我建议您考虑使用图中所示的架构。（箭头是 PK-FK 关系的“多”端。）

这种方法通过在单独的表中记录删除来保持引用完整性并避免使用空值。

您可能还想添加一个“ProductDataChangedOnDate”功能来记录那个讨厌的管理员所做的更改:-)

【讨论】：