我正在構建一個數據庫系統，並且遇到了我的一個表的設計問題。數據庫設計：複合鍵的替代？
在該系統中有一個用戶表，對象表中，項目表和成本表。
成本表中的唯一記錄由用戶，對象，項目和年份決定。但是，如果項目不同，則可能有多個具有相同年份的記錄。
的層次去用戶>對象 - >用品 - >一年，每件多獨特年，每個對象有多個獨特的項目，每個用戶的多個唯一對象，多個獨立用戶。
什麼是設計成本表的最佳方式？
我想包括用戶ID，OBJECTID和爲itemid爲外鍵，然後使用由用戶ID，objecid，itemid的和costyear複合鍵。我聽說組合鍵是不好的設計，但我不確定如何構造這個來避免使用組合鍵。正如你可以告訴我的數據庫建設技能有點生疏。
謝謝！
P.S.如果它很重要，這是一個interbase數據庫。
要避免組合鍵，您只需定義一個代理鍵。這具有人爲的價值，例如自動計數器。
您仍然可以（也應該）在這些列上定義唯一約束。
BTW：它不僅建議不要使用組合鍵，這也是推薦使用代理鍵。在你所有的桌子上。
使用內部生成的密鑰字段（稱爲代理鍵），類似CostID，用戶永遠不會看到，但將唯一標識Cost表中的每個條目（在SqlServer中，像uniqueidentifier或IDENTITY這樣的字段可以做到這一點。 ）
+1：代理鍵遠勝於組合鍵。大多數時候，他們是完成所有密鑰的正確方法。 – 2009-10-07 15:48:23
我以前看過這個回覆，但我很難看到這將如何解決我的問題。該記錄由所有其他四列的組合唯一標識。你能給我一個例子，說明如何查詢數據庫以檢索基於上述4個輸入的記錄？ – kgrad 2009-10-07 15:49:12
完全相同的方式，如果字段表示鍵。 SELECT * FROM Table WHERE User = @User等等。 – 2009-10-07 15:51:07
嘗試使用完全列出所列的組合鍵來構建數據庫，然後查看會發生什麼情況。你可能會感到驚喜。確保這四列中沒有丟失數據，並確保在所有四列中沒有兩行具有相同的值，這有助於保護數據的完整性。
在聲明覆合主鍵，列在申報的順序不會影響dclaration的邏輯後果。但是，DBMS爲您構建的組合索引也將具有相同順序的列，並且組合索引中列的順序確實會影響性能。
對於僅指定一個，兩個或三個這些列的查詢，該指數將是無用的，如果在索引中的第一列是在查詢未指定的列。如果您事先知道您的查詢對我的影響，以及哪些查詢最需要快速運行，這可以幫助您以正確的順序聲明主鍵的列。在極少數情況下，創建兩個或三個額外的列索引可以加速某些查詢，但會以減慢更新速度爲代價。
對於組合鍵和唯一約束！ – 2009-10-07 16:23:45