database - 为什么负 id 或零被认为是不好的做法？

Question

为什么在数据库表中插入主键时，负 id 或零被认为是不好的做法？

我认为它在某些情况下可能很有用，但人们说不推荐这样做，尽管他们从不说/不知道为什么。

所以，我想知道根据定义是否存在一些限制，或者它是否应该没有任何问题，或者它是否只是一个约定，如果确实有一些限制，为什么不阻止该功能？

Answer 1

需要明确的是，这个问题和答案是关于使用负数作为代理键，而不是自然键。

据我所知，认为这是一种不好的做法有三个原因。

1. 它违反了最小意外原则。
2. 有些人认为所有身份证号码都是非负数。
3. 有些人使用负数来表示错误。

第一个有一定的道理。您永远不会在 SO 上看到使用负 ID 号的 SQL 示例或答案。（我要改变它，从今天开始。）

第二个和第三个是第一个的推论，因为程序员经常假设没有意外的行为。（这让我想起了发现 VBA 可以让我将两个日期相乘，返回一个我猜想以平方日期表示的数字。）

对于第 2 点，应用程序程序员可能会因为不允许登录 UI 代码的空间而引入细微的错误，这可能会使 -123456 看起来像 123456。

第三个与编写返回 id 号的代码有关。返回单个 ID 号的代码可能会返回 -1 作为错误代码。但在大多数情况下，-1 是有效的 ID 号。（大多数数据库不将 id 编号限制在非负整数范围内。）

Answer 2

@Mike Sherrill 'Cat Recall' 的答案恕我直言不正确。

负数：ID 不使用负数的原因是负数不可移植。十进制值的二进制表示取决于底层数字架构，这会影响负十进制值以非负流格式（例如，十六进制、base36 等）呈现的方式。类似地，不使用浮点值作为标识符，即使在单一架构的约束下它在理论上是可能的。

零：零可以作为 ID。但不建议这样做，因为它通常表示空字段/ NULL 值。

Answer 3

有超过 5100 万个网站在讨论这个问题。

我同意@Mike Sherrill 的观点，NULL/空字段或负 ID 在确定真实值时可能会产生严重的问题。它根本没有提供信息的目的，只会导致错误的答案和对数据库本身的不信任。

允许零值、负值进入您的列会给您的数据库带来全新程度的不确定性。SQL 程序员必须进行猜测，以应对数据库中 NULL 值的错误结果。