Question

我想谈谈SQL Server中IDENTITY约束的缺点。在我看来，这是有帮助的，但可能会导致外键异常。

示例：

create table letters
(
    ID int identity,
    letter varchar(1)
)

现在我要创建两个字母：

insert into letters (letter) values ('a');
insert into letters (letter) values ('b');

并创建一个每个字母的引用表：

create table references
(
    ID int identity,
    ID_letter int references letters(ID),
    value int
)

我想参考＆＃39; b＆＃39;这封信让我这样做：

insert into references (ID_letter,value) values (2,100)

但现在如果我删除＆＃39; a＆＃39;信件和执行插入＆＃39; b＆＃39;在另一个数据库中，我必须将该引用更改为1而不是2，因为＆＃39; b＆＃39;现在是1。

这就是为什么我宁愿使用name作为主键并引用name，而不是ID身份。但是对于更长的varchars，示例城市来说并不容易 - 写一个城市的ID而不是全名更容易。你有什么看法？

Answer 1

我的观点是你误解了身份是什么。这也是一个广泛的话题。

身份只是特定行的（唯一）编号。除非您这样做，否则它不会自动成为主键或其他键它也不是数据库范围，它绝对不是全球唯一的。除非你做错了什么，否则它不会以那种方式使用。

标识通常用作主键，以避免必须创建多行的复合键，因为它使查找更容易，并减少了索引的大小。即使它是一个键，它也不必是表的聚簇索引，而只能是非聚簇索引。这是一个相关的虽然仍然是替代路线，所以我不会在那个方向上走得太深。

因此，身份永远不会导致外键异常。您对身份的使用可能会导致问题，但这取决于您尝试做的事情，而不是工具本身。

如果您希望数据密钥在多个数据库中保持一致，则可以使用各种“系统密钥”。通常建立在数据本身或从数据计算。为此，您通常会使用uniqueidentifiers（guids），在应用程序中生成的序列号，或者在字母表的情况下，它自己的字母是有效的比较键。

当涉及到城市时，如果您确定要处理拼写，则可以使用该名称，否则，您将根据您想要一起交谈的两个系统之间的逻辑以及如何使用另一个标识符你交换数据。

同样在交叉数据库时，主键并不是自动相同的，两者之间的引用更是如此;即使数据很容易相关。因为它很大程度上取决于数据的使用方式（这再次引导我们回到索引的构建）。

Identity只是数据库工具箱中的一个工具。你如何使用它取决于你，但作为任何工具，它更适合某些任务而不适合每项任务。