数据库方法 - 冗余数据答案

【问题标题】：Database Approach - Redundant data数据库方法 - 冗余数据
【发布时间】：2011-07-22 14:46:52
【问题描述】：

我有 3 张桌子：

products (id, name, price, etc)
orders (id, date, payment_method, etc)
shipments (id, order_id, product_id, address, etc)

我的问题是：将产品 ID 保存在发货表中是否正确？我把它放在这里是为了在不使用订单表的情况下查找有关已发货产品的信息。

【问题讨论】：

订单不包含产品吗？在我看来，一个订单有 1->n 个产品和 1->n 个发货。不是这样吗？
如果您在同一个订单上有两种产品，您会怎么做？
为什么要这样？您只需要编写适当的连接即可从正确规范化的架构版本中获取数据
一个订单只有一个产品。

标签： mysql duplicates redundancy

【解决方案1】：

我建议：

products (product_id, name, price, etc)
orders (order_id, date, payment_method, etc)
orderitem (orderitem_id, order_id, product_id, ...)
shipment (shipment_id, order_id, ... )

发货有点多余 - 我会将地址等添加到订单中...

【讨论】：

【解决方案2】：

你可以这样做，但要小心 - 如果表 order 中的信息可能发生变化，那将是一个问题 - 即如果表 order 中的相应记录更改了 product_id，则数据库将不一致。

我确实使用了多余的列，例如在静态字典中。

还要检查数据库设计的标准形式 (NF)，我不确定这种冗余是否不违反某些标准形式。但是，是否保留一些 NF 取决于您。

【讨论】：

product 表中的信息为当前价格，而 order/shipment 表中的信息为订单发货时的价格。所以这不会真正违反数据库设计原则——一个是模板，一个是该模板的实例。
@MJB 刚才我想到了一些事情。用户可以查看订购产品的历史记录。如果管理员编辑有关产品的信息（名称、描述）会发生什么？现在为避免此问题，如果订购产品，产品将被锁定。
@morandi3：一些系统还支持对商品进行不同“修订”的概念（例如车型年份或特定地区的变化）。

【解决方案3】：

遵循真与美的原则，您不应该存储冗余数据 - 这是一个发生错误的好机会，它很丑陋，它会导致未来开发人员的头脑混乱。

你可以打破真与美的原则，但前提是你遇到了无法以任何其他方式解决的问题。例如，如果您发现通过加入 orders 表查询太慢，那么非规范化数据（这是您正在做的事情的技术名称）是可以的 - 如果您记录它并确保所有开发人员都理解。

仅仅避免查询中的额外连接似乎不是一个足够好的理由......

【讨论】：