DateTime作爲倉庫的FACT表中的PK的一部分

我通常知道將DateTime列作爲PK是不太好的想法，但對於我的情況，我認爲它比事實表中的代理鍵更有意義。DateTime作爲倉庫的FACT表中的PK的一部分

的原因是...

插入到事實表中的數據始終是連續的。即我永遠不會插入比事實表中的最後一個值早的日期時間值。
日期時間字段不是PK的唯一列（複合PK），PK當然是它自己的維度和FK的替代關鍵字。
我查詢數據的方式幾乎總是基於時間。
事實表上的代理鍵會告訴我關於該行的任何信息。每一行都是唯一的，爲了找到這個特殊的事實，我總是會首先在日期時間和維度中的值上過濾。
沒有單獨的日期時間維度表。沒有要求現在或在可預見的將來有指定時間點等

副筆記 - 時間將在UTC和使用SQL 2008 R2。

我在問的是給出的情況 - 這樣做的缺點是什麼？我會遇到無法預料的問題嗎？以後再查詢這些數據時，這樣做是件好事嗎？

想知道DateTime字段上的人物視點作爲複合PK的第一列。

來源

2011-05-27 Gary Howlett

這幾乎是任何數據倉庫的基本特徵，日期/時間是大多數表中的一個鍵的組成部分。這沒有什麼「錯誤」。

一個代理鍵通常不應該是只有表的關鍵，所以也許你的問題是「我是否也應該在我的表上創建一個代理鍵？」。我的建議是，如果你沒有理由創建代理鍵，那麼不要。創建代理人的時間是當你發現你需要它的時候。

來源

2011-05-27 10:55:12 sqlvogel

我一直在做一些思考 - 具體圍繞頁面拆分。我看到了數據可能不會順序進入事實數據表的情況，即一些舊數據可能會進入事實。如果PK先在日期聚集，那麼頁面可能需要重新組織。因此，我認爲我會把PK作爲日期時間和FK的維度，但不要將它聚集在一起。然後生病有一個代理鍵（身份）作爲羣集索引 - 即使生病可能永遠不會在我的任何查詢中使用它。這應該會帶來更快插入的優點，並且quesring應該具有相同的速度。 – 2011-05-27 13:11:24

定義密鑰是邏輯設計的問題。定義羣集是一個物理設計問題。不要混淆兩者。並且將歷史數據聚集在任何你所保存歷史記錄的對象身上，實際上可能使閱讀順序更快，而不僅僅是「等速」！ – 2011-05-27 14:06:23

大多數事實表具有複合鍵和日期時間，或者通常是DateKey, TimeKey是它的一部分。其實很常見。

dimDate和dimTime僅用於避免在查詢的子句WHERE子句中出現「有趣的」日期時間函數。例如

-- sales on 
-- weekends for previous 28 weeks 
-- 
select sum(f.SaleAmount) 
from factSale as f 
join dimDate as d on d.DateKey = f.DateKey 
where d.IsWeekend = 'yes' 
    and d.WeeksAgo between 1 and 28 ;

所以我在這裏可以對IsWeekend和WeeksAgo指數（DateKey太）。如果這些被日期時間函數替代，則會導致逐行處理。

來源

2011-05-27 12:54:12

DateTime作爲倉庫的FACT表中的PK的一部分

回答

相關問題