数据库设计时，每个表要不要都设置自增主键ID！（转）

- 日理万妓 2021-12-03 16:01 949阅读 0赞

# [逻辑数据库设计 - 需要ID(谈主键Id)][- _ID_Id] #

本文的目标就是要确认那些使用了主键，却混淆了主键的本质而造成的一种反模式。

# 一、确立主键规范 #

每个了解数据库设计的人都知道，主键对于一张表来说是一个很重要，甚至必需的部分。这确实是事实，主键是好的数据库设计的一部分。**主键是数据库确保数据行在整张表唯一性的保障**。它是定位到一条记录并且确保不会重复存储的逻辑机制。主键也同时可以被外键引用来建立表与表之间的关系。

难点是选择那一列作为主键。大多数表中的每个属性值都有可能被很多行使用。例如姓名，电子邮件地址等等都不能保证不会重复。

在这样的表中，需要引入一个对于表的域模型无意义的新列来存储一个伪值。这一列被用作这张表的主键，从而通过它来确定表中的一条记录，即便其他的列允许出现适当的重复项。这种类型的主键列我们通常称其为伪主键或者代理键。

大多数数据库提供一种和当前处理事务无关的底层方案，来确保每次都能生成全局唯一的一个整数作为伪主键，即使客户端此时正发起并发操作。

主键存在的作用：

1、确保一张表中的数据不会出现重复行。

2、在查询中引用单独的一行记录。

3、支持外键。

# 二、反模式：以不变应万变 #

很多的书、文章以及程序框架都会告诉你，每个数据库的表都需要一个主键，且具有如下三个特性：

(1)、主键的列名都叫做Id；

(2)、数据类型是32位或者64位的整数

(3)、主键的值是自动生成来确保唯一的。

在每张表中都存在一个叫做Id的列是如此地平常，甚至Id已经成为了主键的同义词。很多程序员在一开始学习SQL时就被灌输了错误的概念。认为每张表都要增加一列Id，这显然太过于随意。

1、冗余键值

2、允许重复项

一个组合键包含了多个不同的列，组合键的典型场景就是想上节中乱穿马路中的Contact表。主键需要确保一个给定的Product\_Id和Account\_Id的组合在整张表中只能出现一次，虽然同一个值可能在很多不同的配对出现。

然而，当你使用了Id这一列作为主键，约束就不是Account\_Id和Product\_Id的组合必须唯一了。当你用这张交叉表去查询Account\_Id和Product\_Id的关系时，重复项会意料之外的结果。要确保没有重复项，你可以在Id之外，额外声明另外两列需要一个UNIQUE约束。但是当你在Account\_Id和Product\_Id这两列上应用了唯一性约束，Id这一列就会变成了多余的列。它已经背离了主键的初衷了。

![27221840-3d025e5cc1784df7a73d17dd34568e5b.jpg][]

3、关键字意义不明确

Id这个词是如此地普通，完全无法表达更深沉的意思，特别是在你做两张表连接查询，而他们都有一个叫做Id的主键时。

select *
    　　from Accout as a
    　　join Bug b on (b.toId = a.Id)

这种查询必须在查询时指定列别名，否则其中的一个Id列会覆盖掉另一列的Id的值。

同时有两张表有相同的Id列的情况下也不能够使用using关键字。

比如：SQL支持一种简洁的表达式来表示两张表联结(using)。如果两张表有同样的列名，就可以用如下的表达式来重写上面的需求。

select * from Account join Bug using(Bug_id);　　--一个主键，一个外键。

然而，如果所有的表都要求定义一个叫做id的伪主键，那么将不能使用这种简写方式。

4、使用组合键

一些开发人员觉得组合键太难使用，如果要比较两个键值，必须比较其包含的所有列的值；一个引用组合键的外键，其本身也必须是一个组合外键。此外，使用组合键需要打更多的字。其实这是不对的。组合键的适当的时候是应该被使用的。

# 三、识别反模式 #

1、我觉得这张表不需要主键。

这么说的人一定是误解了“主键”和“伪主键”的含义，每张表都必须要有一个主键，这个是毫无疑问的。实际上可能这个人需要的是一个组合键，或者一个更自然的列名来做主键。

2、我怎么能在多对多的表中存储重复的项？

在一个对多对关系的交叉表中需要声明一个主键约束。或者至少需要有一个针对那些被引用作为外键的唯一约束。

# 四、合理使用发模式 #

**使用伪主键，或者通过自动增长的整型的机制本身没有什么错误，但不是每张表都需要一个伪主键，更没有必要将每个伪主键都定义成Id。**

对于太长而不方便实现的自然键来说，伪主键是一个很好的代替品。比如在一个记录文件系统的所有文件属性的表中，文件路径是一个很好的自然键，但对一个字符串列做索引的开销会很大。

# 五、解决方案：裁剪设计 #

主键是约束而非数据类型。你可以定义任意列或任意多个的列作为主键。只要其数据类型支持索引。另外在此必须要补充的是，在SqlServer中，主键和聚集索引并没必然的关系。SqlServer只是默认将聚集索引建在主键上，实际上你完全可以将聚集索引手动定义到非主键列。

1、为主键选择更有意义的名称

比如为Product这张表的主键应该叫做Product\_Id。

2、外键应该尽可能地和所引用的列使用相同的名称，这通常意味着：一个主键的名称应该在整个数据库的设计中唯一；任意两张表都不应该使用相同的名称来定义主键，除非其中之一引用了另外一个作为外键。然而凡是都有例外，又是外键的名称需要和其所引用的主键区分开，从而使的它们之间的引用关系表现得更加清晰。

比如在一张外键表中将外键声明为create\_by(由谁创建)。

<table> 
 <tbody> 
  <tr> 
   <td><strong>规则</strong></td> 
   <td><strong>自然键</strong></td> 
   <td><strong>代理键</strong></td> 
  </tr> 
  <tr> 
   <td>主键必须唯一的识别每一记录</td> 
   <td>但与输入和人为错误有关</td> 
   <td>系统自生成的数据是唯一的</td> 
  </tr> 
  <tr> 
   <td>一个记录的主键不能为空</td> 
   <td>只有数据可知时才能输入记录</td> 
   <td>当记录生成时才被系统建立</td> 
  </tr> 
  <tr> 
   <td>当生成记录时，主键的值必须存在</td> 
   <td>只有数据可知时才能输入记录</td> 
   <td>当记录生成时才被系统建立当记录生成时才被系统建立</td> 
  </tr> 
  <tr> 
   <td>主键必须保持稳定——你不能更改主键的域</td> 
   <td>自然键与一些商业规则和其他外部影响有关</td> 
   <td>代理键对程序功能和数据保持中立</td> 
  </tr> 
  <tr> 
   <td>主键必须简洁，不要包含过分的属性</td> 
   <td>一个自然键可以包含多个域</td> 
   <td>代理键只能包含多个域</td> 
  </tr> 
  <tr> 
   <td>主键的值不能改变</td> 
   <td>自然键通常改变</td> 
   <td>代理键通常不更改<br><br></td> 
  </tr> 
 </tbody> 
</table>

# 六、拥抱自然键和组合键 #

如果你的表中包含一列能够确保唯一、非空以及能够用来定位一条记录，就别仅仅因为传统而觉得有必要再加上一个伪主键。

实践证明，一张表中的每一列都在最初的设计之后遭遇改变是很正常的事情。数据库的设计趋向于在整个项目的声明周期中不断地调整和优化，并且决策者也可能一点也不在乎自然键的“神圣不可侵犯”。有时候一个列最开始是像是个很好的自然主键，但随后有允许合法的重复项。此时伪主键便成了唯一的选择。

在合适的时候也可以使用联合主键，比如一条记录可以通过多个列的组合完全定位。就像上面提到的Contact表，那就通过那些列创建一个联合主键吧。

总结：我个人的见解就是能用代理键就尽量用代理键。除非代理键真的非常多余，就好似上面的组合键代替复合键的例子一样。

转自：[https://www.cnblogs.com/fuqiang88/articles/3817301.html][- _ID_Id]

转载于:https://www.cnblogs.com/miaolyou/p/11116506.html

[- _ID_Id]: https://www.cnblogs.com/fuqiang88/articles/3817301.html
[27221840-3d025e5cc1784df7a73d17dd34568e5b.jpg]: /images/20211203/d31e20c73dea436fb80e6f5a69f34f27.png