数据库设计复合键

Question

我将使用一个人为的例子：一个总部有一个或多个联系人。联系人只能属于一个总部。

---

  

TableName =总部

     

第0列= Id：Guid [PK]
  第1列=名称：nvarchar（100）
  第2列= IsAnotherAttribute：bool

     

---

---

  

TableName = ContactInformation

     

第0列= Id：Guid [PK]
  第1栏=总部编号：Guid [FK]
  第2列= AddressLine1
  COlumn 3 = AddressLine2
  第4列= AddressLine3

     

---

我想在这里帮助设置表主键和外键吗？
以上如何看待？
我应该在[第0列和第1列]上使用ContactInformation的复合键吗？ 是否可以一直使用代理键？

Answer 1

我会远离复合键。代理密钥问题值得商榷，但如果我可以使用它，我总是使用INT Identity列（在SQL Server中）。如果数据库必须支持复制或合并分布式数据，我只使用GUIDS。

我认为除了GUID之外，你的列看起来还不错。

Answer 2

如果每个联系人都属于多个总部，那么您只需要在ContactInformation的第0列和第0列上使用复合键;因为你需要相反，你所描述的应该可以正常工作。

就个人而言，如果我真的需要，我只会使用Guids。否则坚持使用。我也倾向于在任何地方使用代理键。

Answer 3

我会说你的主键应该是Id。 ContactInformation Id和HeadquarterID的{​​{1}}上的复合键可能有意义，如果您经常将这两个信息一起使用，但我更喜欢仅使用Id作为如果你真的需要，你可以在Id和HeadquarterID创建一个索引。

Answer 4

除了代理键（您的GUID ID）之外，通常最好识别基于定义实体的业务属性的业务密钥（自然密钥/域密钥）。

使用当前的表设计，没有什么能阻止你添加两个具有相同属性（名称，总部，地址等）的联系人。这通常是不可取的，因此您可以在定义联系人的属性上添加复合自然键。由于PK已经定义，因此Inatural键将是这些属性的唯一约束/索引。

我同意PK应该简单而不是复合。复合PK是一种真正的痛苦，查询变得更加复杂。

Answer 5

想象这是使用复合键或代理项之间的选择是错误的。代理键实现了与其他属性的关键约束完全不同的东西。代理不会阻止这些属性值被复制，因此如果你只使用一个或另一个密钥，那么表的含义就会大不相同。

您应该实现所需的任何密钥，以确保数据的唯一性和完整性。如果这意味着使用复合密钥和代理项，那么就这样做。

话虽如此，我不清楚你的例子中可能的键是什么。如果Id是ContactInformation的候选键，那么（HeadquarterId，Id）不是 - 它是超级密钥，但它不是不可简化的。