你会发现很多关于这个问题的帖子,你会做出的每一个选择都有其优点和缺点.这些参数通常是指关系数据库理论和数据库性能.

关于这个问题,我的观点非常简单：代理主键总是有效,而自然键可能不会总是工作这些天,这有多种原因：字段太短,规则改变等.

到目前为止,您已经猜到我基本上是uniqueIdentifier / surrogate主键团队的成员,即使我欣赏和理解这里提到的论点,我仍然在寻找“自然”的情况.关键比代理更好……

除此之外,支持这一基本规则的最重要但总是被遗忘的论据之一与代码规范化和生产率有关：

每次我创建一张桌子,我都会失去时间

>识别其主键及其物理特征(类型,大小)
>每次我想在我的代码中引用它时记住这些特征？
>向团队中的其他开发人员解释我的PK选择？

我对所有这些问题的回答都是否定的：

>当代理选项为我提供防弹解决方案时,我没有时间试图找出“最好的自然主键”.
>当我编写代码时,我不想记住我的Table_wake的主键是一个10个字符长的字符串.
>我不想浪费时间谈判自然钥匙长度：“好吧,如果你需要10,你为什么不把12安全放在一边？”.这个“安全方面”的说法真让我烦恼：如果你想保持安全,那就意味着你离不安全的一面真的不远了！选择代理：它是防弹的！

所以我在过去的五年里一直在使用一个非常基本的规则：每个表(我们称之为’myTable’)都有第一个名为’id_MyTable’的字段,它是uniqueIdentifier类型.即使这个表支持“多对多”关系,其中字段组合提供了一个非常可接受的主键,我更喜欢创建这个’id_myManyToManyTable’字段作为uniqueIdentifier,只是为了坚持规则,因为,最后,它没有伤害.

主要优点是您不必再关心代码中主键和/或外键的使用.获得表名后,就会知道PK名称和类型.一旦知道数据模型中实现了哪些链接,您就会知道表中可用外键的名称.

如果您仍然希望在桌子的某个位置放置“自然键”,我建议您按照标准模型(如

Tbl_whatever

   id_whatever,unique identifier,primary key
   code_whatever,whateverTypeYouWant(whateverLengthYouEstimateTheRightOne),indexed
   .....

其中id_是主键的前缀,code_用于“自然”索引字段.有些人认为code_字段应该设置为唯一.这是事实,可以通过DDL或外部代码轻松管理.请注意,计算了许多“自然”键(发票号),因此它们已经通过代码生成

我不确定我的规则是最好的.但这是一个非常有效的！如果每个人都在应用它,我们会避免时间丢失回答这类问题！