Database design 何时选择不将标识/自动编号字段用作主键？

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

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

切中要害的是：我的经验和我们任何人一样，都是有限的。还有哪些真实的例子导致人们选择不使用自动编号列作为表的主键，为什么

---

这对我来说是一种“开阔视野”的事情，我希望能从那些使用过大量数据库的人身上学到一些东西，他们有着令人信服的理由选择其他数据库。

对于复合键来说，链接表是最明显的选择。

实际上，我唯一能想到的使用标识列的时候是当生成主键所需的字段数量很大时，或者，如果作为主键的字段非常大（如20个字符的字符串）。在所有其他情况下，我宁愿不使用它们

---

没有人会提出关于身份的问题，那就是当数据发生变化时会发生什么。由于键完全基于记录的添加时间，因此在灾难性事件后将数据重新加载到表中是一个真正的问题。现在dbms应该可以帮助您，防止有人截断表，或者切换主键的值……应该这样做。事情发生了，表损坏了，或者数据库更新遇到了问题。使用identity主键时，突然之间，您就陷入了一团混乱，试图找出哪些标识值与哪一行匹配……等等，但您不能，因为标识值对于数据没有任何意义。对于少量的条目，您可能还可以，但是当您开始使用包含数百万个值的较大表时（发生这种情况时，我们的表略多于1100万个），这会很快成为问题。每个人都会说，“这是一个更糟糕的情况，它永远不会发生。”直到它发生为止。

IMHO使用标识列是至关重要的，因为即使是最简单的表在将来也可能变得更重要

---

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

我坚信技术主键的使用几乎毫无例外，所以我的答案必须是。。。从来没有。

我没有使用自动编号字段的一个领域是将DateDimension表定义为星型架构的一部分时。在本例中，我使用了一个整数，表示yyyymmdd格式的日期。这允许在中心事实表和DateDimension之间进行快速联接（就像自动编号ID列一样）。然而

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

一般来说，我不太喜欢包含业务信息的密钥。通常，您在设计模式时对主键所做的假设随着时间的推移不会成立，您会变得不稳定。在这种情况下，我相当肯定日期不会

我的经验法则是：“如果要在正常使用中添加记录，请使用自动增量PK；如果是静态表，请使用更“自然”的标识符”

---

IOW：用户、历史记录、资产；所有人都会得到一个自动递增PK。zip/城市、类型/描述、机器ID通常会获得一个“自然”键。

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

---

这种用法在大多数情况下不会突然出现，但我的工作涉及大量的批处理，每个批都会合并到主数据库中，以供以后分析/使用。

Iain Hoult、Javier和TK表达的原则的一个例外是使用员工编号或“徽章编号”作为人员表的主键。在这种情况下，PK可以被称为“有意义的密钥”，因为我们已经将员工人事记录的PK交给了员工

---

-Al.

在用户表上，您的PK是什么？他们的用户id？我希望没有人结婚并想更改他们的用户id，将所有FK更改为新的用户id将是一个真正的痛苦！此外，我想说的是，如果您确实使用标识，您应该在“真实”数据列上添加其他约束，以确保数据完整性，例如唯一约束等。在这种情况下，我相信您会将标识列称为“代理密钥”。当然，这一切都取决于您实际建模的数据。当密钥可以根据某些外部问题（业务逻辑、用户突发奇想等）更改时，您需要和代理密钥，除非您没有FK或希望使用新值更新所有FK。1。级联更新2。如果您更改了PKs，那么您确实没有选择一个好的主键。3.是的，它应该是用户id。简单的解决方案，不允许人们更改它。你见过多少次用户id的变化？婚姻与此无关。这可能是一个安全风险，你不允许。如果您真的关心更改用户id，则应禁用该帐户并创建一个新帐户。@Kevin，在我们的系统中