我打算使用一个人为的例子：一个总部有一个或多个联系人。联系人只能属于一个总部。数据库设计复合键
表名=总部
列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）不是 - 它是一个超级键，但它不是无法减少的。