我的数据库表中是否应该始终有主键？
我们采取SO标记。您可以在任何修订中看到该标记，它可能位于带有postID和修订号的tag_rev表中。我需要PK吗？
此外，因为它在rev表中并且当前没有使用标签应该是一串tagID而不是多个post_id tagid对的多个条目？
答案 0 :(得分：10)
表格应该有一个主键，以便您可以使用它唯一地标识每一行。
从技术上讲，你可以拥有没有主键的表，但是你将破坏良好的数据库设计规则。
答案 1 :(得分：9)
您应该努力在任何非平凡的表中使用主键，您可能希望通过该键访问（或更新或删除）单个记录。主键可以包含多个列，从形式上讲，它将是最短的可用超级键;也就是说，最短的可用列组，它们一起唯一地标识任何行。
我不知道Stack Overflow数据库模式是什么样的（以及我在Jeff的博客上看过的一些我不想要的东西），但在你描述的情况下，它完全有可能存在是帖子标识符，修订号和标签值的主键;当然，这将是最短（也是唯一）的超级密钥。
关于你的第二点，虽然赞成在归档表中聚合值可能是合理的，但它确实违背了表中每个行/列交集应该包含一个单一值的原则。虽然它可能会略微简化开发，但没有理由不能保留带有版本化元数据的规范化表格，即使对于像标记这样简单的东西也是如此。
答案 2 :(得分：4)
请参阅此相关问题，了解是否需要整数主键。其中一个答案使用标记作为示例：
Are there any good reasons to have a database table without an integer primary key
有关标记和键的更多讨论，请参阅此问题：
答案 3 :(得分：4)
我倾向于同意大多数表应该有一个主键。我只能想到两次没有意义的事情。
基本上，如果你正在编写一个可能需要在外键关系中引用的表，那么主键很重要，如果你不能肯定它不会，那么只需添加PK。 ：）
答案 4 :(得分：3)
从MySQL 5.5参考手册部分13.1.17：
如果你没有PRIMARY KEY并且应用程序要求表中的PRIMARY KEY，MySQL会返回第一个没有NULL列的UNIQUE索引作为PRIMARY KEY。
所以，从技术上讲，答案是否定的。但是，正如其他人所说，在大多数情况下它非常有用。
答案 5 :(得分：1)
我坚信每张桌子都应该有办法唯一地识别记录。对于99％的表，这是一个主键。对于其余的你可能会得到一个独特的索引（我想这里有一列查找类型表）。任何时候我不得不使用表格而无法唯一地识别记录，就会出现问题。
我也相信如果你使用代理键作为你的PK，你应该尽可能在构成自然键的任何字段组合上有一个单独的唯一索引。我知道有很多次你没有真正的自然键（名称不是唯一的或者什么使得一些独特的东西可能分散在几个父表中），但如果你有一个，请请确保它具有唯一索引或创建为PK。
答案 6 :(得分：0)
如果没有PK，您将如何更新或删除单行？这是不可能的！说实话，我已经使用了几次没有PK的表，例如存储活动日志，但即使在这种情况下也建议有一个，因为时间戳不够精细。临时表是另一个例子。但根据关系理论，PK是强制性的。
答案 7 :(得分：0)
答案 8 :(得分：0)
由于我使用Subsonic，我总是为所有表创建一个主键。许多DB Abstraction库需要主键才能工作。
注意：这并不能回答你问题的“大统一理论”基调，但我只是说在实践中，有时你必须为每张桌子制作一把主键。
答案 9 :(得分：0)
如果它是一个连接表，那么我不会说你需要一个主键。例如，假设您有表PERSONS，SICKPEOPLE和ILLNESSES。 ILLNESSES表有流感，冷等等，每个都有一个主键。 PERSONS有关于人的常见内容，每个人都有一个主键。 SICKPEOPLE表中只包含生病的人，它有两列，PERSONID和ILLNESSID，外键返回各自的表，没有主键。 PERSONS和ILLNESSES表包含实体和实体获取主键。 SICKPEOPLE表中的条目不是实体，也不是主键。
答案 10 :(得分：-1)
数据库本身没有密钥，但它们的组成表可能有。我认为你的意思是，但以防万一...
无论如何，具有大量行的表应该绝对具有主键;只有几行的表不一定需要它们，尽管它们不会受到伤害。这取决于表的用法和大小。纯粹主义者会将主键放在每张表中。这没错;并且在小表中都没有省略PK。
编辑添加关于此问题的博客条目的链接，其中我讨论了数据库管理人员认为没有必要在特定表中包含主键的情况。我认为这充分说明了我的观点。