您何时选择不使用身份/自动编号字段作为主键？

Question

我不相信Silver Bullet，但我真的喜欢使用序列或自动编号标识列作为数据库表的主键列。它们是唯一的，它们索引很好，我不必担心空值。

另一方面，在某些情况下，当表中有其他唯一列可以用于相同目的时，它们似乎是多余的。比如说，您正在构建一个将9位邮政编码映射到城市区域的表格。邮政编码字段也可以正常工作（前提是您可以保证数据格式且不重复值）。

重点：我和我们任何人的经历都是有限的。还有哪些实际例子让人们选择不来使用自动编号列作为表的主键，为什么？

这对我来说是一种“开阔视野”的东西，我希望从那些曾经使用过多数据库并且有充分理由选择其他人的人那里学到一点。

Answer 1

恕我直言，使用标识栏至关重要，因为即使最简单的表格在未来也会变得更加重要。

我唯一不会使用的地方就是我使用GUID的地方，因为在可能需要与中央系统同步的断开连接的客户端上创建记录的情况。

Answer 2

链接表会成为复合键的最明显选择

Answer 3

我的经验法则是：“如果您要在正常使用情况下添加记录，请使用自动增量PK;如果它是静态表格，请使用任何标识符更”自然“”

IOW：用户，历史记录，资产;都获得了自动增量PK。 zip / city，类型/描述，机器ID，通常会获得“自然”键。

Answer 4

我坚信几乎毫无例外地使用技术主键，所以我的答案必须是......永远不会。

Answer 5

在需要频繁数据转储/加载/合并并且我有外键关系的情况下，我通常会避免使用auto_increment列。尝试合并使用自动递增ID的同一模式的两个表实例中的数据是一个可怕的问题。

这种用法并不适用于大多数情况，但我的工作涉及大量批处理，然后将每个批次合并到主数据库中供以后分析/使用。

Answer 6

真的唯一一次我能想到使用标识列的时候是制作主键所需的字段数很大，或者主键的字段是否很大（如20个字符的字符串） 。在所有其他情况下，我不想使用它们。

每个人都不会提出有关身份的问题，就是当数据出现问题时会发生什么。由于密钥仅基于添加记录的时间，因此在灾难性事件发生后将数据重新加载到表中是一个真正的问题。现在dbms应该帮助你，防止有人截断表，或切换主键的值...应该。事情发生，表被破坏，或数据库更新遇到问题。使用身份主键，突然之间你就会弄得一团糟，试图弄清楚哪一个身份值与哪一行有关......等等除了你不能，因为身份值对于数据没有任何意义。有一些条目，你可能没问题，但是当你开始拥有可能有几百万个值的较大表时（当发生这种情况时，我们的价值略高于1100万），这很快就会出现问题。每个人都说，“这是一个更糟糕的情况，它永远不会发生。”直到它确实如此。

Answer 7

我没有使用自动编号字段的一个区域是将DateDimension表定义为星型模式的一部分。在这个例子中，我使用了一个整数来表示yyyymmdd格式的日期。这允许中央事实表和DateDimension之间的快速连接（也作为自动数字ID列）。但是......

DateDimension表包含其他日期表示（例如smalldatetime列，dayOfWeek列等）。如果用户只想要yyyymmdd格式的日期，则不需要连接，因为中央事实表中的日期维度键已经存储了此信息。

一般来说，我不是包含商业信息的密钥的忠实粉丝。通常，您在设计架构时对主键的假设不会随着时间推移而变得正确，您将变得不稳定。在这种情况下，我非常确定日期不会！

Answer 8

Iain Hoult，Javier和TK表达的原则的一个例外是使用员工编号或“徽章编号”作为人员表的PK。在这种情况下，PK只能被称为“有意义的密钥”，因为我们已经向员工提供了他的人事记录的PK。

-Al。