为什么数据库devise者不能使IDENTITY列从最小值而不是1开始？
正如我们所知，在Sql Server中， IDENTITY (n,m)表示值将从n开始，增量值为m ，但是我注意到所有的数据库devise者都将Identity列设置为IDENTITY(1,1) ，而没有利用从(-2,147,483,648) to (2,147,483,647)的所有int数据types的值，
我打算将所有标识列设置为IDENTITY (-2,147,483,648, 1) （标识列对应用程序用户是隐藏的）。
这是一个好主意吗 ？
如果你发现20亿的价值是不够的，你会发现这个数字是不够的（在一个项目的整个生命周期内，需要的数量是其最初devise的两倍多）罕见的*），所以你需要完全采取不同的方法（可能长的价值，可能是完全不同的东西）。
否则，你只是变得奇怪而且无法读取。
另外，谁没有一个数据库，他们知道，例如项目312是一个具有一些不错的特点testing特定的东西？ 我知道我头上有一些随意的东西在烧。 他们可能称之为“这么好，他们两次这样命名”，但是我一直认为纽约是“城市657”，覆盖了我们大部分的testing案例。 这只是一个速记，但-2147482991不会那么方便。
*添加一点。 有些事情你可能会说“啊约100”，发现它实际上是110，好吧。 与其他人一起，实际上你会发现其实是10万人 – 你已经超出了数量级。 数字越高，越是经常出现这样的错误，最终导致数十亿的估计与最终得到数十个答案的估计不同。 如果你估计200是你在特定情况下的最大值，那么你可能应该留下几百个空间。 如果您在特定情况下估计了20亿美元，那么您应该留出几十亿美元的余地。 也就是说，我唯一一次看到有人真正开始在一个负二十亿美元的ID，他们最终有约3000行。
如果你的代码中有一个代表你的表的类（这很可能发生），那么每次你创build一个新的对象时，它将被默认分配ID 0。 如果已经分配了ID 0，则可能导致覆盖数据库中数据的错误。 这也可以很容易地确定一个对象是新的还是来自数据库， if (myObject.ID != 0)
在SQL Server端负ID是好的，像正数处理，所以你可以做到这一点。
其他人是对的，你应该考虑不同的build议，但主要的问题是连接到你的数据库的应用程序。
让我们说拿MS环境。 下面是一个示例： .NET DataSet在自动增加的 id-s上使用负面的ID -s来跟踪代码中的更改。 所以你会有麻烦，因为：
负数键用于行的临时实例。
这里是参考： MSDN
所以明确地说，在MS Enviroment中为MSSQLdevise一个这样的数据库并不是一个好主意。
使用整数接近于零的“良好”副作用之一是，它们易于使用，易于开发人员和testing人员记住，特别是考虑到debugging和unit testing。
此外，代理键有一个讨厌的习惯，爬到业务术语，例如用户可能会看到坐在浏览器顶部的URL查询string中的PK – 数字中的数字越多，他们越容易误导某些东西在帮助台查询中。
所以这就是为什么我很高兴在1而不是在-2147483231种下自己的身份的原因，相反，就像@Jon所build议的那样，随时可能会变成一个BIGINT ，我桌上有20亿行。
当你从负数转换到正数ID时，你将会过零。 这意味着（假设你实际上插入了几十亿行），你最终将有一个零的标识符。 这本身并不坏，但是可能会给ORM工具带来潜在的边缘情况，或者只是简单的应用程序代码，难以区分零和空值。
对于在虚拟数据需要与真实数据混合以进行testing的实时环境中进行testing，负ID可能非常有用，然后在testing完成后将其丢弃。 这应该只有很好的理由 – 我只使用过一次技术。
对于pipe理员而言，负面ID在单行，只读表（即没有事务，表中没有可执行的SQL运行）中也是有用的。
除了这些特定的目的，身份值<= 0将产生比光更多的热量。
