我打算使用一個人爲的例子：一個總部有一個或多個聯繫人。聯繫人只能屬於一個總部。數據庫設計複合鍵
表名=總部
列0 =編號：GUID [PK]
列1 =名稱：爲nvarchar（100）
第2列= IsAnotherAttribute：布爾
表名= ContactInformation
列0 =編號：GUID [PK]
列1 = HeadquarterId：GUID [FK]
第2列= AddressLine1
柱3 = AddressLine2
第4列= AddressLine3
我想在這裏設置表主鍵和外鍵的幫助嗎？
上面是怎麼看的？
我應該在[列0和列1]上使用ContactInformation的組合鍵嗎？
所有的時間都可以使用代理鍵嗎？
我會遠離組合鍵。代理關鍵問題值得商榷，但如果我可以避開它，我總是使用INT Identity列（在SQL Server中）。如果數據庫必須支持複製或合併分佈式數據，那麼我只使用GUIDS。
我認爲你的列看起來不是GUID。
我想說你的主鍵應該是Id。對IdContactInformation和HeadquarterID複合鍵可能是有意義的，如果你會使用這些兩條信息經常在一起，但我寧願只使用Id一個鍵，然後你可以Id和HeadquarterID創建索引，如果你真的需要至。
如果每個聯繫人可能屬於多個總部，則只需在ContactInformation的第0列和第1列上使用複合鍵;既然你需要相反的話，你所描述的應該可以正常工作。
就個人而言，我只會使用Guids，如果我真的需要。否則堅持嵌入。我也傾向於幾乎在任何地方都使用代理鍵。
除了替代鍵（您的GUID ID），通常是一個好主意，可以根據定義實體的業務屬性來識別業務鍵（自然鍵/域鍵）。
在現在的餐桌設計中，沒有任何東西可以阻止你添加兩個具有相同屬性（姓名，總部，地址等）的聯繫人。這通常是不可取的，因此您可以在定義聯繫人的屬性上添加複合自然鍵。由於已經定義了PK，因此Inatural鍵將成爲這些屬性的唯一約束/索引。
我同意PK應該是簡單而不是複合。複合PK是一個非常痛苦的工作，查詢變得更加複雜。
想象這是使用複合鍵或代用品之間的選擇是錯誤的。代理鍵與其他屬性的關鍵約束完全不同。代理不會阻止這些屬性值的重複，因此如果您只使用一個或另一個密鑰，那麼表的含義會非常不同。
您應該實施您需要的任何密鑰以確保數據的唯一性和完整性。如果這意味着使用複合密鑰以及替代品，那麼這樣做。
話雖如此，我不清楚你的例子中可能的關鍵是什麼。如果Id是ContactInformation的候選鍵，那麼（HeadquarterId，Id）不是 - 它是一個超級鍵，但它不是無法減少的。