复合键与 BigInt 主键 - 哪个是较小的邪恶？答案

【问题标题】：Composite key vs. BigInt primary key - which is the lesser evil?复合键与 BigInt 主键 - 哪个是较小的邪恶？
【发布时间】：2013-09-08 23:17:58
【问题描述】：

我有一个实体框架模型，其中包含一个预计会保存大量数据的表。我担心使用 int 主键，因为我希望它会变得更大。我正在考虑使用 Int64 来解决这个问题。

这是真正的关键 - 我在有问题的表上使用每个类型继承的表。因此，如果我使用 Int64，将有几个其他表（实际上是任意数量的表，因为我将添加更多）必须使用 Int64 主键，即使它们增长超出 int 范围的可能性很苗条。似乎是一个低效的解决方案。想法？

我正在考虑使用由 int ID 和子类型鉴别器（可能是 char）组成的复合键。我想知道这种方法对性能的影响。我一直更喜欢代理键，除非它是一个简单的关联实体。有没有比这两种方法更好的方法？以下哪一条路线更可取？

更新：

我想澄清一下，我正在考虑的复合键不是自然复合键。它只包含 ID 和子类型鉴别器。我有兴趣使用它来避免 int 主键的大小限制。我主要担心的是：

1) 使用 Int64 主键是否存在性能问题？尤其是在每个类型继承的表中，它仅对父表是必需的，但也必须在子表中使用。

2) 与使用 Int64 键执行相同操作相比，使用复合键（非自然）实现比 int 主键更大的范围是否提供任何性能优势？

【问题讨论】：

除了意见，你还期待什么样的答案？
我听到了，但意见可以帮助我权衡选择。
你为什么不存根一个基本的应用程序来演示你将如何使用数据库并分析每个设计？我最初的意见是不要担心它并选择最有意义的方法，目前这似乎是bigint 解决方案。数据库可以非常有效地处理整数值，如果这成为您的第一个主要问题，我会感到惊讶。
我更喜欢有一个 single 键——即使它是一个代理并且存在一个“真正的”自然键。如果您只需要在单个列上加入，它只会让加入该表变得更加容易 - 而不必让 2、3、5 或 10 个复合键列在整个模型中波动 -只是这样你就可以加入....
没有必要妥协。您不需要只选择一个。表可以有多个键。同时使用连接和 FK 的单个代理键，以及确保数据一致性的复合自然键。

标签： .net entity-framework composite-primary-key bigint table-per-type

【解决方案1】：

请查看this SO question / answer。基本上，为什么不同时使用两者？对连接和外键使用整数代理键，但确保存在有意义的复合自然键（如果正确的自然键是复合键），以确保数据一致性并最大限度地减少插入重复行的风险...

BigintId  firstName LastName   Phone        Gender   Birthdate
  1         Bob      Smith    111 234-5678    M     1 jan 1978
  2         Bob      Smith    111 234-5678    M     1 jan 1978
  3         Bob      Smith    111 234-5678    M     1 jan 1978
  4         Bob      Smith    111 234-5678    M     1 jan 1978

这些真的是不同的实体，只是因为它们有不同的 id 吗？只有当我们盲目地重新定义 different 以简单地表示它具有不同的 Key...

【讨论】：