为什么将主键存储在另一个表中，而不是使用自动增量？答案

【问题标题】：Why would primary keys be stored in another table, instead of using auto-increment?为什么将主键存储在另一个表中，而不是使用自动增量？
【发布时间】：2017-09-05 08:39:25
【问题描述】：

在使用关系数据库的第三方软件（mssql，但这个问题不限于这个特定的数据库）我看到了以下构造：

多个表具有整数主键，它们不是自动递增的。相反，当前最高的主键（每个表）存储在另一个表中。该表仅包含两列：tableName 和 currentPrimaryKey。

每当在其中一个表中插入新行时，都会使用存储过程来锁定主键表，获取下一个要使用的主键，并解锁主键-再次表。

我的问题是：与简单地使用自增主键相比，这种结构有什么优势吗？

【问题讨论】：

我会说这是旧设计。我以前在软件中看到过，然后在以后的版本中它转移到了身份。
存储在另一个表中的不是主键本身，而是每个表的主键的最后一个或下一个值。主键是一组唯一标识表中行的列。
这是用户实现的自动增量功能替代品。我
您可以获得一些奇怪的功能，因为您可以在需要时手动覆盖自动排序。我并不是说这是个好主意。
另外，如果你在一些缺乏自动增量的环境中，你可以实现这个。这些环境多年前就存在了。

标签： sql-server database database-design

【解决方案1】：

它将保证没有间隙的顺序分配，IDENTITY 不保证，并且在某些法律/监管制度下可能需要。

以序列化所有插入为代价，如果不要求没有间隙，这是一个很高的成本。（IDENTITY 而是在任何事务的“外部”起作用，因此如果事务回滚，则该特定身份值未被使用）

【讨论】：

接受了，因为它提供了实际的优势，但可能很少需要。

【解决方案2】：

与简单地使用自增主键相比，这种结构有什么优势吗？

在大多数场景中，不，这听起来像是一种获取唯一 ID 的古老机制。使用内置工具来完成他们设计的工作。

可能存在您有多个表或数据库的情况，您希望在这些表或数据库中为某些业务规则保持键的唯一性。但如果它只是一个表，那么我会坚持使用内置的自动增量。

每当在其中一个表中插入新行时，都会使用存储过程来锁定主键表，获取下一个要使用的主键，并解锁主键-再次表。

这样，根据您系统的流量，它可能会导致延迟，因为当查找表需要在涉及的任何表中插入新行时，它会被锁定。延迟可能是微不足道的时间量，但流量越大，延迟就会越高。

此外，这些代码都是有人必须管理和维护的，而内置机制是为您管理的。

【讨论】：

【解决方案3】：

软件供应商通常希望他们的产品支持多个 DBMS 和不同版本的 DBMS。 MySQL 没有内置的独立于表的序列生成器。 SQL Server 在 SQL Server 2012 之前也缺乏这样的功能。基于专用表的序列生成器是实现此类序列的常见解决方法，而无需依赖任何特殊的 DBMS 功能。

也许软件供应商也希望避免使用不同版本的列绑定“自动递增”序列生成器。例如，SQL Server 不允许更新自动递增列（又名 IDENTITY 列），而 MySQL 允许更新。如果软件供应商仅依赖每个 DBMS 中的内置功能，那么他们的产品在不同 DBMS 上的行为可能会有所不同。

【讨论】：