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

Question

我想知道，使用自动增量主键作为业务实体标识符（例如Partner Idor ）是坏主意还是好主意Account Number？

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

Answer 1

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

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

在我们的产品中，我们总是在主键旁边使用“自然键” ，即人类可以理解的键。

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

Answer 2

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

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