关于重复信息的数据库设计问题答案

【问题标题】：Database Design Question regarding duplicate information关于重复信息的数据库设计问题
【发布时间】：2010-04-07 18:10:31
【问题描述】：

我有一个包含产品销售历史的数据库。例如下表

CREATE TABLE SalesHistoryTable (
OrderID, // Order Number Unique to all orders
ProductID, // Product ID can be used as a Key to look up product info in another table
Price, // Price of the product per unit at the time of the order
Quantity, // quantity of the product for the order
Total, // total cost of the order for the product. (Price * Quantity)
Date, // Date of the order
StoreID, // The store that created the Order
PRIMARY KEY(OrderID));

该表最终将有数百万个事务。由此，可以为不同地理区域的产品创建配置文件（基于 StoreID）。作为数据库查询，创建这些配置文件可能非常耗时。例如。

SELECT ProductID, StoreID,
 SUM(Total) AS Total,
SUM(Quantity) QTY,
SUM(Total)/SUM(Quantity) AS AvgPrice
FROM SalesHistoryTable
GROUP BY ProductID, StoreID;

上述查询可用于根据任何特定商店的产品获取信息。然后，您可以确定哪家商店卖得最多，赚的钱最多，平均卖得最多/最少。这将是非常昂贵的使用作为一个正常的查询运行随时。假设存储大小不是问题，有哪些设计决策可以让这些类型的查询运行得更快。例如，我可以创建另一个包含重复信息的表。商店 ID（键）、产品 ID、TotalCost、QTY、AvgPrice 并提供一个触发器，以便在收到新订单时，在新表中更新该商店的条目。更新的成本几乎为零。

在上述情况下应该考虑什么？

【问题讨论】：

您自己的答案是针对此类查询的。在数据库中缓存结果将比您可以做的任何其他事情提供更大的加速。这种方法的另一个好处是，如果事情由于某种原因不同步，您可以在紧要关头扔掉所有东西并使用一个查询重新创建表。

标签： database database-design

【解决方案1】：

这通常是您使用数据仓库的目的，但除此之外，使用触发器更新第二个表是一个完全可行的选择。

您还可以有一个由批处理作业定期填充的第二个表（更类似于数据仓库的选项）。如果您的数据库支持，您也可以使用物化视图。

【讨论】：

【解决方案2】：

我会考虑：

数据仓库/OLAP 解决方案
（如您所说）针对单独的预计算表/数据集运行数据挖掘查询
与上一点几乎相同的索引/物化视图

还有一些问题：

您希望获得实时数据吗？
您的写入量是多少？
什么数据库引擎？

【讨论】：

+1：数据可以是实时的，当然会继承延迟延迟。我想像 Eric 提到的那样，放入批处理作业并以每小时 1 次或类似的速度更新数据可能是一种选择。写入量大约为 >1000/天。但是我可以访问 2006 年的数据。我还不确定，因为我还没有创建和导入数据，但我猜有超过 150 万行信息。

【解决方案3】：

您可能想考虑使用materialized views，它只会被定期查询。

【讨论】：

+1：谢谢，我还没有听说过物化视图。我一定会调查的。

【解决方案4】：

“更新的成本几乎为零。”

除了现在必须序列化所有更新。因为不管怎样，古老的物理定律仍然是没有两件东西可以同时在同一个地方。

【讨论】：

我想我明白你在说什么，但我不确定这如何适用。如果每小时有 1000 次销售，则意味着 1000 次插入到 SalesHistoryTable 和 1000 次触发器，导致 2 次添加和除法 + 行更新。这似乎比运行查询 1000 次要便宜得多，对吧？
也许我应该将我的声明更改为“与查询相比，更新的成本几乎为零”？这可能是相对的一点。