我通常知道將DateTime列作爲PK是不太好的想法,但對於我的情況,我認爲它比事實表中的代理鍵更有意義。DateTime作爲倉庫的FACT表中的PK的一部分
的原因是...
- 插入到事實表中的數據始終是連續的。即我永遠不會插入比事實表中的最後一個值早的日期時間值。
- 日期時間字段不是PK的唯一列(複合PK),PK當然是它自己的維度和FK的替代關鍵字。
- 我查詢數據的方式幾乎總是基於時間。
- 事實表上的代理鍵會告訴我關於該行的任何信息。每一行都是唯一的,爲了找到這個特殊的事實,我總是會首先在日期時間和維度中的值上過濾。
- 沒有單獨的日期時間維度表。沒有要求現在或在可預見的將來有指定時間點等
副筆記 - 時間將在UTC和使用SQL 2008 R2。
我在問的是給出的情況 - 這樣做的缺點是什麼?我會遇到無法預料的問題嗎? 以後再查詢這些數據時,這樣做是件好事嗎?
想知道DateTime字段上的人物視點作爲複合PK的第一列。
我一直在做一些思考 - 具體圍繞頁面拆分。我看到了數據可能不會順序進入事實數據表的情況,即一些舊數據可能會進入事實。如果PK先在日期聚集,那麼頁面可能需要重新組織。因此,我認爲我會把PK作爲日期時間和FK的維度,但不要將它聚集在一起。然後生病有一個代理鍵(身份)作爲羣集索引 - 即使生病可能永遠不會在我的任何查詢中使用它。這應該會帶來更快插入的優點,並且quesring應該具有相同的速度。 – 2011-05-27 13:11:24
定義密鑰是邏輯設計的問題。定義羣集是一個物理設計問題。不要混淆兩者。並且將歷史數據聚集在任何你所保存歷史記錄的對象身上,實際上可能使閱讀順序更快,而不僅僅是「等速」! – 2011-05-27 14:06:23