2011-05-24 46 views
8

我有一個相當簡單的問題關於自然/代理關鍵用法在一個明確定義的上下文,這往往體現自己,我要說明。複合主鍵和自然/代理鍵使用的影響

我們假設您正在爲使用SQL Server 2005作爲DBMS的產品設計數據庫模式。 爲了簡單起見,我們假設只涉及兩個實體,它們已被映射到2個表格Master,Slave。 假設:

  1. 我們可以有0..N單個碩士排奴隸條目;
  2. 列集(A,B,C,D) in Master是唯一候選人爲主鍵;
  3. Column B in Master is 隨時間變化;
  4. A,B,C,D是varchar,decimal和bigint列的mix

問題是:你將如何設計這些表的鍵/約束/引用? 你願意(argumenting你的選擇):

  1. 實現對主複合自然鍵上(A,B,C,d),並從一個相關的複合外鍵,或
  2. 在主服務器上引入代理鍵 K,假設有一個IDENTITY(1,1)列,並在從服務器上有一個相關(單列)外鍵,在主服務器(A,B,C,D) ,或
  3. 使用不同的方法。

至於我,我會選擇2),主要是因爲假設3)和表現明智,但我想聽聽其他人的意見(因爲在這個話題上有一個公開的辯論)。

謝謝

+0

編輯:Master中的列集(A,B,C,D)是**主鍵的唯一候選者** – 2011-05-24 12:37:41

回答

5

要麼1,2或3. ISN的選擇的情況下不一定有足夠的信息來確定代孕是否有必要,或者它可能有多大用處。是否有任何複合關鍵屬性也是從屬表中某個關鍵或約束的一部分?是否還有一些Master可以用作外鍵的其他鍵?關鍵值可能改變的事實不應該是決定性因素,因爲任何關鍵值都可能需要改變 - 代理人也不例外。

有相當多的 話題

不幸的是公開辯論,以至於爭論的是基於您需要或者替代或自然鍵之間進行選擇錯誤的假設。正如你的選擇2正確地建議你可以在需要時使用兩者。一個不能替代另一個,因爲不同屬性上的簡單鍵和複合鍵顯然意味着數據模型中的不同事物,並對數據執行不同的約束。

6

你的假設,(3)傾向於建議選擇(2),因爲它是不便和潛在的耗時處理師父當B修改的主鍵的級聯更新。當然,這取決於這種情況的發生頻率:如果這是你期望「隨時」發生的事情,那麼它表明(A,B,C,D)是主鍵的糟糕選擇;另一方面,如果它很少發生,那麼(A,B,C,D)可能是主鍵的一個好選擇,並且在Slave中擁有這些列可能有一些優點(不需要加入所有的主找出那些列值)。

8

我會選擇2.保持簡單。

它爲有用的聚集索引(這是SQL Server中的PK的默認值)打勾框(窄,數字,不變,嚴格單調遞增)。

如上所述,您需要強制使用A,B,C,D上的唯一性來保持數據的完整性。

選項1在概念上沒有任何問題,但只要您需要「主」上的更多索引,那麼廣泛的集羣密鑰就會成爲負債。或者做更多的工作來確定哪個索引最適合聚類。

編輯:

在任何混亂

其中聚簇索引的選擇是獨立於關鍵

+1

當設計或創建表或主鍵時,數據庫設計者/開發者/ DBA決定聚集指數應該是。在選擇主鍵時沒有意義,因爲它恰好是聚集索引的一個好候選。選擇主鍵和聚簇索引是單獨的決定,應該保持分開。 – sqlvogel 2011-05-24 12:42:33

+0

@dportas:正確,這是一個實施決策,不是一個建模問題。實際上,對於普通的米老鼠數據庫或沒有「數據庫」團隊的人來說,這並不重要。 – gbn 2011-05-24 12:48:33

+0

我沒有讓你失望,但如果你同意不應該選擇聚集索引來確定關鍵的選擇,那麼我認爲你沒有回答OP的問題。在我讀到它的時候,你的回答似乎支持這樣一種誤解:主鍵選擇應該由聚集索引的一個好選擇來決定。做出區分很重要,因爲很多人似乎對鍵和索引之間的差異感到困惑。 – sqlvogel 2011-05-24 13:53:29

0

三。

第一個建議可能是drop composte鍵,併爲自動鍵添加一個新字段,這與其他字段無關。到主表和詳細表。

它可能是一個整數自動增量鍵或全局唯一標識符。在任何S.Q.L中保留組合鍵服務器品牌是困難的,有時甚至是非常困難的。

但是,如果您需要將複合鍵保留在主表中,您可能仍然想知道如何處理從表主鍵。許多開發人員通常從主表中獲取主鍵的相同字段,將其放在從屬/明細表上,並添加一個額外的連續整數鍵。但是,正如您所提到的,如果您必須更改主表的關鍵字並保留已存在的詳細信息行,則會引入參考完整性約束問題。

總結:我建議,添加一個新的領域從表中,是不相關的主表,字段添加到從屬/詳細信息表的外鍵,引用主表。將詳細主鍵和外鍵保持爲主表,獨立。