我不相信银弹，但我真的很喜欢使用序列或自动编号标识列作为数据库表的主键列。它们是独一无二的，它们的索引很好，而且我不必担心空值。
另一方面，在某些情况下，当表中还有其他可以用于相同目的的唯一列时，它们似乎是多余的。例如，假设您正在构建一个表格，将 9 位邮政编码映射到城市区域。邮政编码字段也可以正常工作（前提是您可以保证数据格式并且没有重复值）。
直截了当：我的经验，就像我们任何人一样，是有限的。还有哪些现实世界的例子导致人们选择不使用自动编号列作为表的主键，为什么？
这对我来说是一种“拓宽视野”的事情，我希望向那些使用过多数据库并有令人信服的理由选择其他方式的人学习一些东西。
恕我直言，使用标识列至关重要，因为即使是最简单的表在未来也会变得更加重要。
我唯一不使用 GUID 的地方是我使用 GUID，因为可能在断开连接的客户端上创建了记录，然后需要与中央系统同步。
我的经验法则是：“如果要在正常使用中添加记录，请使用自动增量 PK；如果是静态表，请使用更“自然”的标识符”
IOW：用户、历史记录、资产；都得到一个自动增量PK。zip/city、类型/描述、机器 ID，通常会得到一个“自然”键。
链接表是复合键最明显的选择
我几乎无一例外地坚信使用技术主键，所以我的答案必须是......永远不会。
在需要频繁转储/加载/合并并且我有外键关系的情况下，我通常会避免使用 auto_increment 列。尝试合并来自使用自动递增 id 的相同模式的两个表实例的数据是一个可怕的问题。
这种用法在大多数情况下不会出现，但我的工作涉及大量批处理，其中每个批处理然后合并到主数据库中以供以后分析/使用。
实际上，我唯一能想到使用标识列的情况是创建主键所需的字段数量很大，或者作为主键的字段非常大（如 20 个字符的字符串）。在所有其他情况下，我宁愿不使用它们。
没有人提出的关于身份的问题是当数据发生某些事情时会发生什么。由于键仅基于添加记录的时间，因此在发生灾难性事件后将数据重新加载到表中是一个真正的问题。现在，dbms 应该可以帮助您并防止有人截断表，或者切换主键的值......应该。事情发生了，表损坏了，或者数据库更新遇到了问题。使用身份主键，突然之间，您会陷入一团糟，试图找出哪些身份值与哪一行搭配......等等，除非你不能，因为身份值对数据没有任何意义. 有少数条目，你可能没问题，但是当你开始有可能有几百万个值的更大的表时（发生这种情况时我们的值略高于 1100 万），这很快就会出现问题。每个人都说，“那是更糟糕的情况，它永远不会发生。” 直到它发生。
我没有使用自动编号字段的一个领域是在将 DateDimension 表定义为星型模式的一部分时。在本例中，我使用了一个整数来表示 yyyymmdd 格式的日期。这允许中央事实表和 DateDimension 之间的快速连接（作为自动编号 ID 列也可以）。然而 ...
DateDimension 表包含其他日期表示（例如 smalldatetime 列、dayOfWeek 列等）。如果用户只想要 yyyymmdd 格式的日期，则不需要连接，因为中央事实表中的日期维度键已经存储了此信息。
一般来说，我不是包含商业信息的密钥的忠实粉丝。通常，您在设计模式时对主键所做的假设不会随着时间的推移而成立，并且您会变得不稳定。在这种情况下，我相当确定日期不会！
Iain Hoult、Javier 和 TK 所表达的原则的一个例外是使用员工编号或“徽章编号”作为人事表的 PK。在这种情况下，只有我们将员工的人事记录的 PK 交给了员工，才可以称其为“有意义的密钥”。
-阿尔。