ruby-on-rails - 复合主键与唯一对象 ID 字段

Question

我继承了一个基于复合键比使用唯一对象 ID 字段更理想的想法构建的数据库，并且在构建数据库时，不应将单个唯一 ID 用作主键。因为我正在为这个数据库构建一个 Rails 前端，所以我在让它符合 Rails 约定时遇到了困难(尽管可以使用自定义 View 和一些额外的 gem 来处理复合键)。

来自编写它的人的这种特定模式设计背后的推理与数据库如何以非有效方式处理 ID 字段以及在构建索引时树排序存在缺陷有关。这个解释缺乏任何深度，我仍然试图围绕这个概念(我熟悉使用复合键，但不是 100% 的时间)。

任何人都可以提供意见或对此主题进行更深入的讨论吗？

Answer 1

大多数常用引擎(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 引擎技术来生成 key ，因此需要更加特化的数据模型才能在不同平台上实现。

代理键的参数倾向于围绕特定于 SQL 引擎的问题:

1) 当业务需求/规则发生变化时，它们可以更轻松地更改属性。 这是因为它们允许将数据属性隔离到单个表中。这主要是 SQL 引擎无法有效实现标准 SQL 构造(例如 DOMAIN)的问题。当属性由 DOMAIN 语句定义时，可以使用 ALTER DOMAIN 语句在架构范围内执行对属性的更改。不同的 SQL 引擎对于更改域具有不同的性能特征，并且一些 SQL 引擎根本不实现 DOMAINS，因此数据建模者通过添加代理键来提高对属性进行更改的能力来弥补这些情况。

2) 它们比自然键更容易实现并发。 在自然键的情况下，如果两个用户同时使用相同的信息集，例如客户行，并且其中一个用户修改了自然键值，那么第二个用户的更新将失败，因为他们的客户代码更新不再存在于数据库中。在代理键情况下，更新将成功处理，因为不可变 ID 值用于标识数据库中的行，而不是可变客户代码。然而，允许第二次更新并不总是可取的——如果客户代码改变了，第二个用户可能不应该被允许继续他们的更改，因为行的实际“身份”已经改变——第二个用户可能正在更新错误的行。代理键和自然键本身都不能解决这个问题。必须在 key 的实现之外解决全面的并发解决方案。

3) 它们的性能优于自然键。 性能最直接地受到 SQL 引擎的影响。由于 SQL 引擎的数据存储和检索机制，使用不同 SQL 引擎在相同硬件上实现的相同数据库架构通常具有截然不同的性能特征。一些 SQL 引擎非常接近平面文件系统，其中当相同的属性(例如客户代码)出现在数据库模式中的多个位置时，数据实际上是冗余存储的。当需要对数据或架构进行更改时，SQL 引擎的这种冗余存储可能会导致性能问题。其他 SQL 引擎在数据模型和存储/检索系统之间提供了更好的分离，允许更快地更改数据和模式。

4) 使用某些数据访问库和 GUI 框架时，代理键可以更好地发挥作用。 由于大多数代理键设计(例如:所有关系键都是整数)的同质性，数据访问库、ORM 和 GUI 框架可以处理信息，而无需对数据具有特殊知识。自然键由于其异构性质(不同的数据类型、大小等)，不能很好地与自动化或半自动化工具包和库配合使用。对于专门的场景，例如嵌入式 SQL 数据库，设计数据库时考虑到特定的工具包可能是可以接受的。在其他场景中，数据库是企业信息资源，由多个平台、应用程序、报表系统和设备同时访问，因此在设计时专注于任何特定的库或框架时无法很好地发挥作用。此外，当引入下一个伟大的工具包时，旨在与特定工具包一起使用的数据库成为一种负担。

我倾向于支持自然键(显然)，但我并不狂热。由于我工作的环境，我帮助设计的任何给定数据库都可能被各种应用程序使用，我使用自然键进行大部分数据建模，并且很少引入代理。但是，我不会特意尝试重新实现使用代理的现有数据库。代理键系统工作得很好——不需要改变已经运行良好的东西。

有一些优秀的资源讨论了每种方法的优点:

http://www.google.com/search?q=natural+key+surrogate+key

http://www.agiledata.org/essays/keys.html

http://www.informationweek.com/news/software/bi/201806814