Question

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

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 并提供触发器，以便在收到新订单时，在新表中更新该商店的条目。更新的成本几乎为零。

在给出上述情况时应该考虑什么？

Answer 1

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

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

Answer 2

我会考虑：

数据仓库/ OLAP解决方案
（正如您所说）针对单独的预先计算的表/数据集
索引/物化视图与前一点几乎相同

但是有一些问题：

你期待实时数据吗？
你的写作量是多少？
什么是数据库引擎？

Answer 3

您可能希望使用materialized views，只会定期查询。

Answer 4

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

除了现在必须序列化所有更新。因为无论如何，古代物理定律仍然是两个东西不能同时在同一个地方。

数据库设计有关重复信息的问题

4 个答案: