Question

order_products表包含产品名称和价格的产品数据。它列出了客户购买的记录。

还有两个名为product_name和price的字段，它们是products表中的重复数据。

为产品名称和价格规范化order_products表并创建历史（审计）表是否值得？那么我不再需要product_name表格中的price和order_products了吗？

Answer 1

我假设您需要在订单时存储product name和price。两者都会随着时间的推移而改变。如果发生很多，您当前的方法可能已经足够好了。

我会考虑采用标准化方法，特别是如果order_products每(product name, price)行有很多行。有一个额外的表，可以在每次更改时存储产品的易失性状态。可以像你已经暗示的那样调用product_history。只需保存每个新状态的日期（或时间戳）。拥有表product的foriegn密钥链接以保持参照完整性。像这样：

create table product_history
(product_id    integer  -- or timestamp
,valid_from    date
,product_name  varchar
,price         decimal
,PRIMARY KEY (product_id, valid_from)
,FOREIGN KEY (product_id) REFERENCES product(product_id)
               ON DELETE CASCADE
               ON UPDATE CASCADE)

快速查询以查找适用的volatile属性：

SELECT *
FROM   product_history
WHERE  product_id = $my_product_id
AND    valid_from <= $my_date
ORDER  BY valid_from DESC
LIMIT  1;

您肯定需要（product_id，valid_from）上的索引才能加快此查询速度。我的例子中的主键可能会这样做。

Answer 2

这取决于。那张桌子的目的是什么？

一般来说，这样的表可以用来对市场趋势进行统计分析，因此同时拥有product_name和price非常重要，因为今天的产品价格可能与一个月前不同，但您可能想知道产品的购买价格最高。

但是，如果该表中的价格存在是由于价格可能是products主键的一部分，那么这只是不好的做法，应该减少密钥。

Answer 3

仅仅了解数据库结构是不可能做出这种判断的。这取决于您如何使用数据库（即插入，选择，更新和删除......以及频率如何？）。

一方面，如果您的解决方案是只读数据库上的报告解决方案，您应该保留这些重复项！但是，如果在另一端，您的解决方案是一个仅记录信息但从未撤消的记录解决方案，那么我会选择您建议的非规范化模型。

完全规范化的数据库未针对性能进行优化。您经常需要 de 规范化您的数据库设计..

通常，具有一定程度冗余数据的模型是最快的模型。非规范化时，你必须时刻关注更快的查询和更慢的插入/更新之间的平衡！

检查这些答案，也许您会找到进一步帮助做出决定！ When to Denormalize a Database Design

Answer 4

是的，这是一个好主意，但更好的想法是在order_products表中创建一个字段，并在序列化后将所有订单信息转储到那里。使用这种方法，您不必创建2个新表（如果您想对礼品券信息，运输信息等进行相同操作，可能会更多）

该方法背后的基本原理是order_products被下订单，这意味着它们是“已发布的记录”。发布的记录变化不大，不应修改。并且应保留这些记录以供将来审核。

order_products表应该非规范化吗？

4 个答案: