为什么负面的id或零被视为不良做法？

Question

在数据库表中插入主键时,为什么将负id或零视为不良做法？

我认为它在某些情况下可能有用,但是人们说它不推荐,尽管它们从不说/知道为什么.

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

Answer 1

要清楚,这个问题和答案是关于使用代号键的负数而不是自然键.

据我所知,有三个理由认为这是一种不好的做法.

第一个有一些有效性.您永远不会在SO上看到使用负ID号的SQL示例或答案.(我将从今天开始改变它.)

第二个和第三个是第一个的推论,因为程序员经常假设没有惊喜的行为.(这让我想起发现VBA会让我乘以两个日期,返回一个可以用方形日期表达的数字.)

对于2号,应用程序员可能会因为不允许登录UI代码而引入细微错误,这可能使-123456看起来像123456.

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

Answer 2

@Mike Sherrill'Cat Recall'的回答是恕我直言.

否定:不对ID使用否定的原因是负数不可移植.十进制值的二进制表示取决于基础数值体系结构,这会影响负十进制值以非负流式格式(例如,十六进制,base36等)呈现的方式.类似地,不使用浮点值作为标识符,即使在单个体系结构的约束内,理论上也是可能的.

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

形式上,标识符是一个标记(在https://en.wikipedia.org/wiki/Identifier中有一个很好的概述),所以只有当你认为它是一个字符序列时才可以将负数视为一个标记,有点蔑视其性质为"消极".因此,在您的问题的上下文中,ID是*数字*而不是字符串,当负数时,此数字*不应*用作ID.这不仅仅是一个建议,因为在"最小惊喜原则"的情况下,恕我直言,使用负面ID是一个错误.也许使用浮点数作为ID的更极端的例子更直观. (2认同)
我认为有多种方法可以备份和移植数据库。二进制备份/可移植性是一种选择，但我们不限于此。真正的错误是依赖物理架构来备份或移植某些东西。正如我所提到的，如果发生这种情况，对于任何其他不可移植的列来说，可移植性仍然是一个问题。所以单纯的PK其实并不能解决任何问题。您的声明不仅仅适用于 PK，它适用于任何数字列，因此如果允许负数，则在任何地方使用它都是错误的，这实际上是无意义的。 (2认同)