我将使用一个人为的例子:一个总部有一个或多个联系人。联系人只能属于一个总部。
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的复合键吗?
是否可以一直使用代理键?
答案 0 :(得分:1)
我会远离复合键。代理密钥问题值得商榷,但如果我可以使用它,我总是使用INT Identity列(在SQL Server中)。如果数据库必须支持复制或合并分布式数据,我只使用GUIDS。
我认为除了GUID之外,你的列看起来还不错。
答案 1 :(得分:1)
如果每个联系人都属于多个总部,那么您只需要在ContactInformation的第0列和第0列上使用复合键;因为你需要相反,你所描述的应该可以正常工作。
就个人而言,如果我真的需要,我只会使用Guids。否则坚持使用。我也倾向于在任何地方使用代理键。
答案 2 :(得分:0)
我会说你的主键应该是Id
。 ContactInformation
Id
和HeadquarterID
的{{1}}上的复合键可能有意义,如果您经常将这两个信息一起使用,但我更喜欢仅使用Id
作为如果你真的需要,你可以在Id
和HeadquarterID
创建一个索引。
答案 3 :(得分:0)
除了代理键(您的GUID ID)之外,通常最好识别基于定义实体的业务属性的业务密钥(自然密钥/域密钥)。
使用当前的表设计,没有什么能阻止你添加两个具有相同属性(名称,总部,地址等)的联系人。这通常是不可取的,因此您可以在定义联系人的属性上添加复合自然键。由于PK已经定义,因此Inatural键将是这些属性的唯一约束/索引。
我同意PK应该简单而不是复合。复合PK是一种真正的痛苦,查询变得更加复杂。
答案 4 :(得分:0)
想象这是使用复合键或代理项之间的选择是错误的。代理键实现了与其他属性的关键约束完全不同的东西。代理不会阻止这些属性值被复制,因此如果你只使用一个或另一个密钥,那么表的含义就会大不相同。
您应该实现所需的任何密钥,以确保数据的唯一性和完整性。如果这意味着使用复合密钥和代理项,那么就这样做。
话虽如此,我不清楚你的例子中可能的键是什么。如果Id是ContactInformation的候选键,那么(HeadquarterId,Id)不是 - 它是超级密钥,但它不是不可简化的。