使用数据库的主键作为业务对象标识符是不是一个坏主意？答案

【问题标题】：Is it a bad idea to use a database's primary key as business object identifier?使用数据库的主键作为业务对象标识符是不是一个坏主意？
【发布时间】：2015-02-07 03:05:31
【问题描述】：

我想知道，使用自动递增主键作为Partner Id 或Account Number 等业务实体标识符是好主意还是坏主意？

另外，如果我选择这种方法，我会面临哪些陷阱？

【问题讨论】：

我不认为您说使用 ID 或数字本身就是一个坏主意。这取决于。通常，ID 和数字是完美的。问问你自己：你还想到了什么其他的关键？而且，那会更好吗？我不认为两者本质上更好。数字的技巧，不是从 1 开始，而是让一个 ID 以 1000000 开头，另一个以 20000000 开头，等等。
@tvCa：我当然不是指 ID 或数字本身。我的意思是作为数据库特定信息的一部分的自动增量 ID。
@Vokinneberg 请澄清您的问题。当您说“作为业务实体标识符”时，这不是一个明确的陈述。我们大多数人会认为业务是面向客户的。但是您的评论表明您的意思是它是表的主键的理想选择。这个问题的答案是，当您将其定义为自动递增列和 PK 时，它绝对非常适合 PK...只要您不生成 GUID...我还要补充一点，显示客户一个自动递增值的帐号就可以了......只要它不是 GUID
@MER 当我说业务标识符时，我指的是面向客户的东西。

标签： sql business-logic object-relational-model

【解决方案1】：

我不认为每个人都有相同的意见，但我确实认为这是不好的做法。在我看来，将 ID 作为“密钥”传递给用户是不好的，原因有很多：

ID 对用户来说并不自然。他们不是在谈论项目“1474623”，而是在谈论项目“ABC”。他们不是在谈论“363528”这个人，而是在谈论“Patrick Hofman”；
ID 很脆弱。你不能真的依赖他们不改变。如果您选择移动到另一个数据库平台或当前平台的新版本，并且您想使用“插入”语句移动所有数据，那么可能会丢失 ID 字段。

在我们的产品中，我们总是在主键旁边使用'natural key'，这是一个人类可以理解的键。

如果没有人类可理解的自然键可用，例如当它是一个日志表时，您可以恢复为人工键。

【讨论】：

根据他们随后发表的评论，我相信 OP 正在询问将其用作他的 PK 是否是个好主意。此外，在与支持开发人员角色的应用程序用户合作多年后，我发现用户实际上倾向于很快锁定 ID 类型编号。如“嘿，你会看@记录号 14567 并告诉我描述是否令人困惑吗？”。我需要注意的是，如果将 GUID 用作 PK，如果是这种情况，那么使用自然键是一个好主意（但在这种情况下，我永远不会向用户显示实际的 PK）。
@mer：我绝对不建议将 pk 替换为 nk。这甚至是不可能的。
我为我的表述不够清楚而道歉。我并不是建议你在哪里告诉他使用自然键作为 PK，（尽管有可能agiledata.org/essays/keys.html（第 2 点），这只是一个坏主意）。我唯一的观点应该是，根据我的经验，用户不喜欢引用数字的想法，但随后很快切换到使用生成的数字作为应用程序中给定记录的主要参考点（记录含义应用程序中显示的所有收集的数据，例如帐户 #、文件 # 或项目 # 等...）。
@mer：我个人的经验是，用户很高兴能够在系统中说他们的语言。
好信息，我同意，拥有某种自然键（或者更好的是名称字段）对于用户在查看@数据时感到舒适很重要。我更多地指的是他们在适应之后实际最终使用的东西，（尽管如果系统在开始时让他们感到厌烦，那么他们永远不会使用它来让他们感到舒服......）。

【解决方案2】：

在选择或设计按键时，您至少应牢记三个理想的特征：简单性、稳定性和熟悉性。在实践中，人们经常发现使用单词和字母而不仅仅是数字更容易记住和工作，这就是为什么字母数字标识符通常比仅数字标识符更常见的原因（字母数字标识符的示例：汽车牌照、航空公司航班号、座位预订号码、州和国家代码、邮政编码、电子邮件地址）。有研究和轶事证据支持字母数字键比单独的数字更有用的想法。此外，字母数字标识符通常比数字标识符短。另一方面，对于某些应用程序（例如发票号码、银行帐号），顺序的纯数字标识符非常常见。所以我建议您在确定这些事情时应该以您的用户/业务需求为指导。

请注意，DBMS 引擎级序列生成器通常带有一些限制，使其不适用于某些应用程序。例如，更新它们或在分布式数据库架构中使用它们可能并不容易。另一个常见的限制是每个表只能允许一个“自动递增”列，如果您还需要同一个表的代理键，则不能将它们用作业务键。

【讨论】：

指出我之前没有评论的余地，自动递增的主键可能是应用程序设计中的一个问题，其中数据必须在多个数据库中是唯一的......在这种情况下是手段到一个 GUID 作为 PK。但是，我要补充一点，我与实际用户使用实际应用程序的轶事经验是，他们认为在最初询问名称时会更容易，但在使用应用程序的几周内，他们引用代理键值的频率远高于名称, （甚至是全数值）。