负键有什么用？

Question

使用标准 SQL 数据库（目前主要使用 MySQL）有点新，我还没有遇到过很多这样的用法。

什么时候以及为什么使用负（或者更确切地说是有符号的）键来索引一个表是有用的？

Answer 1

所有主键都是我们确定的值，该值是记录中最重要的值。无论该键是有符号整数、无符号整数、字符串、blob（实际上是有限制的）还是 UUID（或今天使用的任何名称），事实仍然是它是一个键，并且它是最重要的事情。

由于我们不限于仅对我们的密钥使用正数，因此考虑有符号 int 将仅达到约 20 亿，而无符号 int 将达到约 40 亿是有道理的。但是使用有符号整数并没有错，将初始值设置为 ~ -20 亿并将增量设置为 1。在大约 20 亿条记录之后，您将达到“零”，然后您将继续达到大约 20 亿条记录。

至于为什么在表格中包含“负键”会有所帮助，这与“为什么在表格中包含键会有所帮助”是同一个问题。键的“值”对其作为键的状态没有影响。钥匙是钥匙是钥匙。

重要的是密钥是否有效。

至于为什么允许负键有用，我可以提出一些理由：

如果您想将销售系统中的退货指示为负销售订单编号，这与正销售订单编号匹配，从而使相关性变得容易（这是天真且设计不佳，但它可以在“电子表格”意义上工作），该怎么办？

如果你想要一个用户表，并指出那些负数是系统控制的（SO 就是这样做的，对于聊天提要用户）。

我可以继续，但实际上，负数之所以重要的唯一原因是你或我是否赋予它重要性。除此之外，密钥的价值与密钥本身没有任何关系。

Answer 2

如果我们关于标识或自动编号列，值本身应该没有意义。（有时确实如此，根据 drachenstern 指定的 SO 聊天用户，我在自己之前做过）

但是，如果您使用有符号整数，通常会丢失一半的范围。
请参阅：当表中的字段接近最大有符号或无符号 32 位整数时该怎么办？

另一个例子：在小型复制场景中，对一个站点使用负值，对另一个站点使用正值可以隐式地了解任何给定行的来源。

Answer 3

并非所有数据库系统甚至都支持无符号整数类型，MSSQL 就是其中之一。在这些情况下，整数键字段中可能存在负值，仅仅是因为它们在类型中是可能的（您可以使用规则或触发器来阻止它们，如本例所示，但可能不需要将强制执行此类规则的开销添加到每次插入/更新）。

就数据库而言，主键的实际值并不重要，只要它在表中是唯一的。对它而言，-42 和 42 只是两个不同的数字，就像 42 和 69 一样 - 含义只会通过您的代码赋予值的负数或不负数。

不支持无符号整数类型可能是基于降低复杂性的设计决策 - 即不希望两个不同的 32 位整数类型担心在它们之间分配值时检查范围。它确实限制了从 0 或 1 开始的自动增量字段中可能的索引数量到无符号类型（~2e9 而不是~4e9）中可能的一半，但这很少是一个重要问题（如果您可能需要无论如何，您可能会选择 64 位类型的许多关键值，特别是如果使用 64 位体系结构，其中处理此类值的效率不低于 32 位值），但如果您可能想要完整范围并需要出于空间原因坚持使用 32 位，您可以从 -2,147,483,647 开始增量。