2010-04-07 67 views
1

我有一个包含产品销售历史的数据库。例如下表关于重复信息的数据库设计问题

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

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

+1

您自己的答案是针对这种查询。在数据库中缓存结果将比您能做的任何事情提供更大的加速。这种方法的另一个好处是,如果事情由于某种原因而失去同步,那么可以把所有东西都抛出去,并用一个查询重新创建表。 – roufamatic 2010-04-07 18:14:56

回答

2

这通常是您将使用数据仓库的一种方式,但除此之外,使用触发器更新第二个表是一个完全可行的选项。

您可能还有第二个由批处理作业定期填充的表(更多数据仓库选项)。如果你的数据库支持,你也可以使用物化视图。

+0

+1:谢谢我会研究物化视图。 – galford13x 2010-04-07 19:18:54

1

我会考虑:

  • 数据仓库/ OLAP解决方案
  • (如你所说)运行数据挖掘查询对一个单独的预计算表/数据集
  • 索引/物化视图是如前点几乎相同

有一些问题,但:

  • 您是否期望实时数据?
  • 你的写入量是多少?
  • 什么是数据库引擎?
+0

+1:数据可能是实时的,当然会有延迟延迟。我想可以把批处理作业和数据更新1小时或其他一些东西作为Eric提到的选项。写入量将大于1000 /日。然而,我可以访问2006年的数据。我还不确定,因为我还没有创建和导入数据,但我猜测有超过150万行信息。 – galford13x 2010-04-07 19:22:49

1

您可能想要考虑使用materialized views,它只会定期查询。 “

+0

+1:谢谢,我还没有听说过物化视图。我一定会考虑他们。 – galford13x 2010-04-07 19:17:13

0

”更新的成本几乎没有。“

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

+0

我想我明白你的意思了,但我不确定这是如何适用的。如果每小时有1000个销售额,则这意味着将1000个插入到SalesHistoryTable和1000个触发器中,从而导致2个添加项和一个分部+行更新。这似乎是更便宜,然后运行查询1000次? – galford13x 2010-04-07 19:16:08

+0

也许我应该改变我的陈述,“与查询相比,更新的成本几乎没有什么”?这可能会更相对一些。 – galford13x 2010-04-07 19:18:24