我想谈谈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
)
我想参考"b"字母，以便制作：
insert into references (ID_letter,value) values (2,100)
但现在，如果我删除"a"字母并在另一个数据库中插入"b"，我必须将该引用更改为1而不是2，因为"b"的ID现在是1。
这就是为什么我宁愿使用name作为主键和对name的引用，而不是ID标识。但使用较长的varchars（例如城市）就不那么容易了——写城市的ID而不是全名要容易得多。你的意见是什么？
我的观点是你误解了身份是什么。这也是一个广泛的话题。
标识只是特定行的（唯一）编号。它不会自动成为密钥，无论是主密钥还是其他密钥，除非你这样做。
它也不是数据库范围的，也绝对不是全球唯一的。除非你做错了什么，否则它不会以这种方式使用。
标识经常被用作主键，以避免必须制作多行的组合键，因为这使查找更容易，并减少了索引的大小。即使它是一个键，也不必是表的聚集索引，而可以是非聚集索引。这是一条相关的路线，尽管仍然是另一条路线，所以我不会在这个方向上走得太深。
因此，身份永远不会导致外键异常。你对身份的使用可能会造成问题，但这取决于你想做什么，而不是工具本身。
如果希望数据键在多个数据库中保持一致，可以使用某种"系统键"。通常建立在数据本身或根据数据计算。为此，您通常会使用uniqueidentifiers（guids）、应用程序中生成的序列号，或者在字母表的情况下，字母本身就是一个有效的比较键。
当涉及到城市时，如果你确信拼写会得到处理，你可以使用这个名字，否则，你会根据你想在一起交谈的两个系统之间的逻辑以及你如何交换数据，包括另一个标识符。
此外，当谈到跨数据库时，主键并不是自动意味着相同，两者之间的引用甚至更少；即使数据很容易关联。因为这在很大程度上取决于数据的使用方式（这又让我们回到了索引的构建）。
标识只是数据库工具箱中的一个工具。如何使用它取决于你自己，但作为任何工具，它更适合某些任务，而不是每项任务。