2010-04-07 70 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