我继承了一个数据库，该数据库的构想是复合键比使用唯一对象ID字段更理想，并且在构建数据库时，永远不要将单个唯一ID用作主键。因为我正在为此数据库构建一个Rails前端，所以遇到使它符合Rails约定的困难（尽管可以使用自定义视图和一些其他gem来处理复合键）。
编写此特定架构设计背后的原因与编写数据库的方式有关，这与数据库如何以非有效方式处理ID字段以及在构建索引时树型排序有缺陷。这种解释没有任何深度，我仍在尝试围绕这个概念（我熟悉使用复合键，但并非100％的时间）。
任何人都可以对此主题发表意见或增加深度吗？
Answers:
使用代理密钥系统，大多数常用引擎（MS SQL Server，Oracle，DB2，MySQL等）不会遇到明显的问题。有些人甚至可以通过使用代理来提高性能，但是性能问题是特定于平台的。
一般而言，自然键（以及扩展为复合键）的替代键辩论历史悠久，几乎看不到“正确答案”。
自然键（单数或复合键）的参数通常包括以下内容：
1） 它们已经在数据模型中可用。已建模的大多数实体已经包括一个或多个属性或属性组合，这些属性可以满足创建关系所需的键需求。向每个表添加其他属性会合并不必要的冗余。
2） 他们消除了某些联接的需要。例如，如果您的客户具有客户代码，发票具有发票编号（两者都是“自然”键），并且想要检索特定客户代码的所有发票编号，则可以简单地使用"SELECT InvoiceNumber FROM Invoice WHERE CustomerCode = 'XYZ123'"。在经典的代理键方法中，SQL看起来像这样："SELECT Invoice.InvoiceNumber FROM Invoice INNER JOIN Customer ON Invoice.CustomerID = Customer.CustomerID WHERE Customer.CustomerCode = 'XYZ123'"。
3） 它们为数据建模提供了一种更为通用的方法。使用自然键，可以在不同的SQL引擎之间大体上不变地使用相同的设计。许多代理密钥方法使用特定的SQL引擎技术来生成密钥，因此需要对数据模型进行更多专业化处理才能在不同平台上实现。
代理键的争论通常围绕SQL引擎特定的问题展开：
1） 当业务需求/规则更改时，它们使属性更改更容易。这是因为它们允许将数据属性隔离到单个表中。对于没有有效实现标准SQL结构（例如DOMAIN）的SQL引擎，这主要是一个问题。当通过DOMAIN语句定义属性时，可以使用ALTER DOMAIN语句在架构范围内对属性进行更改。不同的SQL引擎对于更改域具有不同的性能特征，并且某些SQL引擎根本不实现DOMAINS，因此数据建模人员通过添加代理键来提高这些属性的能力，从而弥补了这些情况。
2） 与自然键相比，它们使并发的实现更容易。在自然键情况下，如果两个用户同时使用相同的信息集（例如客户行），并且其中一个用户修改了自然键值，则第二个用户的更新将失败，因为他们是客户代码数据库中不再存在更新。在代理键的情况下，更新将成功处理，因为不可变的ID值用于标识数据库中的行，而不是可变的客户代码。但是，并非总是希望允许第二次更新-如果客户代码已更改，则由于该行的实际“身份”已更改，可能不应该允许第二个用户继续进行更改-第二个用户可能更新错误的行。代理键或自然键都无法单独解决此问题。
3） 它们的性能比自然键好。性能最直接受到SQL引擎的影响。由于SQL引擎的数据存储和检索机制，在使用不同SQL引擎的同一硬件上实现的同一数据库架构通常会具有截然不同的性能特征。一些SQL引擎非常接近平面文件系统，当相同的属性（例如客户代码）出现在数据库架构的多个位置时，实际上将冗余存储数据。当需要对数据或架构进行更改时，SQL引擎的这种冗余存储会导致性能问题。其他SQL引擎在数据模型与存储/检索系统之间提供了更好的隔离，从而可以更快地更改数据和架构。
4） 代理键在某些数据访问库和GUI框架中的功能更好。由于大多数代理键设计的同类性质（例如：所有关系键都是整数），数据访问库，ORM和GUI框架可以使用该信息，而无需对数据有特殊的了解。由于自然键的异构性质（不同的数据类型，大小等），自然键在自动或半自动工具箱和库中无法正常工作。对于诸如嵌入式SQL数据库之类的特殊方案，可以在考虑特定工具箱的情况下设计数据库。在其他情况下，数据库是企业信息资源，可以由多个平台，应用程序，报表系统和设备同时访问，因此在着重于任何特定库或框架的情况下，数据库也无法正常运行。此外，
我倾向于倾向于自然键（显然），但是我并不狂热。由于我所处的环境，我帮助设计的任何给定数据库都可能被各种应用程序使用，因此我将自然键用于大多数数据建模，而很少引入替代方法。但是，我不会竭尽全力尝试重新实现使用代理的现有数据库。代理密钥系统可以正常工作-无需更改已经运行良好的功能。
有一些出色的资源讨论了每种方法的优点：
http://www.google.com/search?q=natural+key+surrogate+key
我从事数据库应用程序开发已有15年了，但我还没有遇到过非代理键比代理键更好的选择的情况。
我并不是说这种情况不存在，我只是说，当您考虑到实际开发访问数据库的应用程序的实际问题时，通常，代理键的好处开始压倒了non的理论纯度。 -代理键。
主键应该是恒定且无意义的; 非代理密钥通常不能满足一项或两项要求，最终
如果密钥不是恒定的，那么将来会有一个更新问题，可能会变得非常复杂
如果密钥不是无意义的，则它更有可能改变，即不是恒定的；往上看
举一个简单的常见示例：一个清单项目表。将项目编号（SKU编号，条形码，部件代码或其他）作为主键可能很诱人，但是一年后，所有项目编号都发生了变化，您将获得非常混乱的“整个更新”数据库问题...
编辑：还有一个比哲学更实际的问题。在许多情况下，您将以某种方式找到特定的行，然后再对其进行更新或再次查找（或同时查找）。使用复合键，可以在WHERE子句中跟踪和更新更多数据，以进行重新查找或更新（或删除）。同时，其中一个关键段可能也已更改！使用代理密钥，始终只保留一个值（代理ID），并且根据定义，它不能更改，这大大简化了这种情况。
这听起来好像谁创建的数据库是在伟大的自然键与代理键辩论的自然键侧的人。
我从来没有听说过ID字段上的btree有任何问题，但是我也没有深入研究它。
我属于代理键方面：使用代理键时，您的重复次数较少，因为您仅在其他表中重复了一个值。由于人类很少手动加入桌子，因此我们不在乎它是否是数字。另外，由于在索引中只需要查找一个固定大小的列，因此可以安全地假设代理也通过主键具有更快的查找时间。
我基本上是代理密钥团队的成员，即使我欣赏并理解JeremyDWill此处提出的论点，但我仍在寻找“自然”密钥比代理更好的情况...
有关此问题的其他帖子通常涉及关系数据库理论和数据库性能。在这种情况下始终被遗忘的另一个有趣的参数与表规范化和代码生产率有关：
每次创建表格时，我都会浪费时间吗
我对所有这些问题的回答都不是：
computer”表的主键是64个字符长的字符串（Windows是否接受这么多字符作为计算机名？）。因此，过去五年来，我一直遵循一条非常基本的规则：每个表（我们称其为“ myTable”）都有其第一个字段“ id_MyTable”，该字段具有uniqueIdentifier类型。即使此表支持“多对多”关系，例如“' ComputerUser”表，其中“ id_Computer”和“ id_User”的组合形成了非常可接受的主键，我还是更愿意将此“ id_ComputerUser”字段创建为uniqueIdentifier，只是为了遵守规则。
主要优点是您不必关心代码中主键和/或外键的使用。获得表名后，便知道PK名称和类型。一旦知道了数据模型中实现了哪些链接，便会知道表中可用外键的名称。
我不确定我的规则是最好的。但这是一个非常有效的！
开发新体系结构的一种实用方法是利用表的替代键，该键将包含成千上万个多列的高度唯一记录和简短描述表的组合键。我通常会发现，大学决定使用代理键，而现实世界中的程序员更喜欢使用组合键。您确实需要将正确类型的主键应用于表-不仅仅是一种方法。
使用自然键会使使用任何自动ORM作为持久层的噩梦。同样，多列上的外键往往会相互重叠，这在以OO方式导航和更新关系时会带来进一步的问题。
您仍然可以在唯一约束中转换自然键并添加自动生成的ID；但这并不能消除外键的问题，但是必须手动进行更改。希望多列和重叠约束将是所有关系中的一小部分，因此您可以集中精力在最重要的地方进行重构。
自然的pk有其动机和使用场景，并且不是一件坏事（tm），他们只是往往与ORM融洽相处。
我的感觉是，与其他任何概念一样，在合理的情况下应使用自然键和表规范化，而不应视作盲目的设计约束
在这里，我将简短有趣：组合主键现在已经不好了。如果可以，请添加替代密钥，并通过唯一约束维护当前密钥方案。ORM很高兴，您很高兴，原始程序员不是那么高兴，但是除非他是您的老板，否则他就可以解决。
复合键可能很好-它们可能会影响性能-但它们不是唯一的答案，就像唯一（替代）键不是唯一的答案一样。
使我担心的是选择组合键的原因中的模糊性。对任何技术的模糊不清往往表示缺乏理解-可能是在书或文章中遵循别人的指南...。
唯一的ID没什么问题-实际上，如果您已将应用程序连接到数据库服务器，并且可以选择要使用的数据库，那么这一切都会很好，并且您几乎可以使用任何键和并没有遭受太大的痛苦。
关于这个问题，已经有并且将会有很多记载，因为没有单一的答案。有一些方法和方法需要以熟练的方式仔细应用。
我在数据库自动提供ID方面遇到很多问题-我会尽可能避免使用它们，但仍会偶尔使用它们。
...数据库如何以无效方式处理ID字段，以及在建立索引时，树排序存在缺陷...
几乎可以肯定这是胡说八道，但可能与在不同会话中以较高的速率向PK分配递增编号时的索引块争用问题有关。如果是这样，那么REVERSE KEY索引可以为您提供帮助，尽管由于块分割算法的更改而导致索引大小变大。http://download.oracle.com/docs/cd/B19306_01/server.102/b14220/schema.htm#sthref998
进行合成，特别是如果它有助于您的工具集更快地进行开发。
我不是一个经验丰富的人，但仍然支持使用主键作为id，这里是使用示例的说明。
外部数据的格式可能会随时间变化。例如，您可能认为一本书的ISBN将成为一本书的主键。毕竟，ISBN是唯一的。但是随着本书的写作，美国的出版业正为重大变化做准备，因为所有ISBN都增加了数字。如果我们将ISBN用作书籍表中的主键，则必须更新每一行以反映此更改。但是然后我们会遇到另一个问题。数据库中还会有其他表通过主键引用books表中的行。除非先阅读并更新所有这些参考，否则我们无法在books表中更改键。这将涉及删除外键约束，更新表，更新books表以及最终重新建立约束。总而言之，这很痛苦。如果我们使用自己的内部值作为主键，问题就会消失。没有第三方可以随便告诉我们更改架构-我们控制自己的键空间。而且，如果确实需要更改ISBN之类的内容，则可以更改它而不会影响数据库中的任何现有关系。实际上，我们已经将行的编织与这些行中数据的外部表示分离了。
尽管解释是很活泼的，但是我认为它以一种简单的方式解释了事情。
@JeremyDWill
感谢您为辩论提供一些急需的平衡。特别感谢您提供有关的信息DOMAIN。
为了保持一致性，我实际上在整个系统范围内都使用代理密钥，但是要权衡利弊。我使用代理键进行诅咒的最常见原因是当我有一个包含规范值简短列表的查找表时—我将使用较少的空间，并且如果我刚创建了这些值，我的所有查询将更短/更轻松/更快。 PK，而不必加入表格。
两者都可以做-因为任何一个大公司数据库都可能会被多个应用程序使用，包括运行一次性查询和数据导入的人工DBA，因此仅出于ORM系统的利益而设计数据库并不总是可行或不理想的。
这些天，我倾向于为每个表添加“ RowID”属性-该字段是GUID，因此每一行都是唯一的。这不是主键，而是主键（如果可能）。但是，在此数据库之上工作的任何ORM层都可以使用RowID来标识其派生对象。
因此，您可能具有：
创建表dbo.Invoice（ CustomerId varchar（10）， CustomerOrderNo varchar（10）， InvoiceAmount money not null， 评论nvarchar（4000）， RowId uniqueidentifier不为null default（newid（））， 主键（CustomerId，CustomerOrderNo） ）
因此，您的DBA很高兴，您的ORM架构师也很高兴，并且数据库完整性得到了保留！
我只想在此处添加一些东西，这些东西在与关系数据库讨论自动生成的整数标识字段时从未见过（因为我经常看到它们），也就是说，它的基本类型可能会在某个时候溢出。
现在，我并不是要说这会自动使复合ID成为可能，但这只是一个事实，即使可以将更多数据逻辑上添加到表中（仍然是唯一的），单个自动生成的整数身份可以阻止这种情况的发生。
是的，我意识到在大多数情况下这不太可能，并且使用64位整数会为您留出很大的空间，并且实际上，如果发生了这种溢出，则数据库的设计可能应该采用不同的方式。
但这并不能阻止某人这样做...使用一个自动生成的32位整数作为标识的表可能会失败，因为该表将在特定快餐公司的全局级别存储所有交易，尝试插入第2,147,483,648次交易时（这是完全可行的方案）。
只是要注意一点，人们倾向于掩饰或完全忽略。如果要定期插入任何表，则应考虑随着时间的推移将多久累积一次数据以及累积多少数据，以及是否甚至应使用基于整数的标识符。