2013-05-31 66 views
1

我正在設計一個基於項目的數據庫,並且需要一些建議來確定如何最好地確定是使用單個主鍵還是複合主鍵?是否使用單個主鍵或複合主鍵?

我們有許多現有的基於項目的獨立數據庫,但從未將它們合併爲一個,即使它們遵循相同的結構。

所有表都基於兩個主要領域

1)項目代碼

2)項目編號

這些事情總是一起和存在的所有表所示。 項目代碼和項目代碼對每個用戶都非常有意義,因爲他們將描述通過項目代碼和項目編號(實際上寫在其上)標識的物理對象。

項目代碼始終是唯一的,而項目編號範圍從1到n(其中n是任何數字但從不重複)。 開始一個新項目,項目編號從1開始。

所以數據庫的基礎如下。

表:項目列表

領域:項目代碼(PK),其他領域...

表:項目列表

領域:項目代碼(FK),項目編號(PK? ),其他領域...

表:任何其他表

領域:項目代碼(FK),項目編號(FK),其他領域...

將項目代碼作爲主鍵有意義 但是,項目代碼不能是主鍵,因爲它不是唯一的。項目編號1-n將在每個項目中重複,但是是每個人的主要參考。

我首先想到的是創建一個名爲的Item_ID代理主鍵這在項目列表表自動遞增,然後使用在所有其他表的外鍵,

所以......它看起來像

表:項目列表

領域:項目代碼(PK),其他領域...

表:項目列表

領域:項目代碼(FK)的Item_ID(PK),項目編號,其他領域...

表:任何其它表

領域:項目代碼(FK)的Item_ID(FK),項目編號,其他領域...

但是,item_ID鍵對使用它的每個人都沒有意義,他們必須不斷詢問什麼是我的物品編號以便將其鏈接到其父表。

我的第二個想法是通過將項目代碼添加到公式中的項目編號PROJECT CODE_ITEM NUMBER E.G.如果項目代碼是「Project1」,則項目編號可寫爲「Project1_24」。這將使項目號碼唯一,因此可以用作主鍵。

(假設子表有自己的PK)。

因此,他們應該是這樣的:

表:項目列表

領域:項目代碼(PK),其他領域...

表:項目列表

領域:項目代碼(FK),項目編號(PK),其他領域...

表:其他表

領域:項目代碼(FK),項目編號(FK),其他領域...

這樣工作,因爲它仍然保留對每個用戶都有意義的項目編號。但它似乎有點冗長,因爲他們每次都必須輸入PROJECT CODE_ITEM NUMBER來作出正確的參考。他們習慣於編寫物品編號。

..可能有一些自動執行這個過程的方法,所以他們仍然可以編寫數字,但是數據庫在它後面添加了項目代碼..我不知道?

我的第三個想法是使項目代碼和項目編號成爲項目列表中的組合鍵,併爲項目列表中的項目代碼創建代理項目代碼。

所以它看起來像這樣:

表:項目列表

領域:PROJECT_ID(PK),其他領域...

表:項目列表

領域:PROJECT_ID( FK),項目代碼(CPK),項目編號,(CPK),其他領域...

表:其他表

字段:Project_ID(FK),項目代碼(CFK),項目編號,(CFK),其他字段...

這樣做可以,因爲輸入項​​目ID相當直接,項目代碼和項目數字在組合使用時會成爲自然的關鍵。他們將永遠在一起記錄任何記錄,並且是獨一無二的。

但是我應該使用哪種方法?

+0

是否使用自然鍵或代用鍵是人們總是爭論的問題。我會說,去與複合鍵,但你應該在這個網站上搜索「代孕鍵」,你會得到理由在兩個參數的sidfes。例如http://stackoverflow.com/questions/63090/surrogate-vs-natural-business-keys –

回答

2

對於你的項目列表我想你會想要一個複合主鍵,因爲你將有多個項目列在這個數據庫中,並且由於項目代碼不是唯一的,所以你需要將它與項目代碼結合起來唯一標識它。

如果你沒有組合鍵,而你試圖映射到唯一不是唯一的時間碼,那麼你將最終得到所謂的笛卡爾積 - 當你的行和行的廢話時查詢數據庫。

數據建模很有趣,建模良好的數據庫非常值得花時間做對。網上有很多書籍和教程可以幫助你,而且不會花太長時間閱讀。

希望這會有所幫助。