7

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

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

4

2 回答 2

6

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

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

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

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

于 2014-12-09T09:25:58.937 回答
3

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

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

于 2014-12-10T09:59:00.697 回答