是否有理由拥有一个整数主键列而不是一个身份列？答案

【问题标题】：Is there a reason to have an integer primary key column not also an Identity column?是否有理由拥有一个整数主键列而不是一个身份列？
【发布时间】：2016-11-15 05:50:44
【问题描述】：

我遇到了一个问题，我需要定期向表中插入记录，但整数主键列不是标识列。如果是这样，插入记录并让它们自动递增以保持唯一性将很容易。但是，我不能使主键列成为标识列，而不会在应用程序中导致错误，而该应用程序有时仍用于完成我正在做的事情。您是否有理由想要一个整数主键而不将该列也作为标识列？我对此有点陌生，只是想知道为什么有人会以这种方式构建表格。

编辑添加：我已经进行了一些谷歌搜索和研究，并且我了解它们的差异和目的，但我找不到任何关于您为什么不想要在此一起使用它们的任何信息特定实例，甚至以您无法做到的方式创建您的表/应用程序。

【问题讨论】：

我的意思是，有有个原因，但我们无法回答您的系统中出现这种情况的原因。例如，如果 int 值具有实际意义并且在表中是唯一的，则可以将其完美地用作主键，而不是使其成为标识
int值没有意义。它纯粹是一个标识符和人工密钥。我只是想知道这些原因是什么，即使它们不是我们系统的具体原因。
再一次，我不知道为什么在你的系统中做出这个决定，但是关于“sql server 为什么不使用身份”的简单谷歌搜索会提供几个链接，其中包含很好的信息。 Here's one of them
正如@Lamak 所说，这是有原因的，这取决于您的系统，但我认为您是在询问示例：如果您正在记录来自外部系统的数据，包括标识符，如果标识符也是外键, 如果速度对大容量插入非常重要，那么标识可能会减慢批量插入的速度，在这种情况下，有办法生成成批的顺序标识符来加速插入，我相信可能还有更多。
这似乎很学术，因为您无法在不破坏其他应用程序的情况下更改它，因此无论是否有充分的理由，您似乎都坚持使用它。

标签： sql-server database-design primary-key identity

【解决方案1】：

IT 对我来说似乎是一个糟糕的数据库设计，表应该有一个可用于搜索和排序的主键，例如用户名作为主键，没有自动增量的整数主键是不好的设计

【讨论】：

【解决方案2】：

是否有理由拥有一个整数主键列而不是一个标识列？

如果您所说的“身份”是指（自动增量为）代理，即组成 DBMS，那么是的：

-- ticket #N is held by person P
lotto(N, P) -- PK(N)

surrogate 只是 DBMS 任意选择的名称/标识符（日常意义上的“识别”），例如用户“3508218”，而不是“asp8811”或“eighty-”八”或“德克萨斯”。请注意，它们是存在于 DBMS 之外的系统中的代理项（“无意义”）。（虽然有些人不会将系统生成的这种名称/标识符称为代理项，如果它在系统外可见。）

PK/UNIQUE 只是表示列集的子行值在表中是唯一的。这里N 确实有一个“含义”，即它是一个事物的名称/标识符，DBMS 无法控制选择。事实上，如果一张票只能由一个人持有，那么 P 也是一个候选键（PK/UNIQUE），无论命名/识别人的值（任何类型）是否是代理项。

每个 PK/UNIQUE 或超集在每个基表和查询结果命名/识别一些的事物种类。即在任何类型上设置的任何列都可以命名/识别事物（与它们为 1:1 或 M:1），无论它是否是候选键（PK/UNIQUE）。所以整数（和任何其他类型或类型集）主键（和唯一）列（和列集）（和超集）到处都是命名/识别，而不是代理，无论它们是否是候选键。

【讨论】：