【问题标题】：When we don't need a primary key for our table?当我们的表不需要主键时？
【发布时间】：2011-03-31 06:24:35
【问题描述】：

我们设计一个不需要主键的表会不会发生？

【问题讨论】：

表中只有一行时
@Shakti @EBAG，这是真的，但是 1) 这什么时候会发生？并且，2) 将数据限制为始终只有一行是不好的做法。更好地设计数据库时考虑到未来。我敢肯定你是在开玩笑，但如果这个问题是合法的，那么 EBAG 需要知道即使只有一行，没有主键也是一个坏主意。
@rockerest - 当您想要一个代表各种配置选项的表时。您想使用不同的列，以便为每个选项使用适当的数据类型（例如，如果您想要某事的重试值，则将其存储为 int）。在这种情况下，您希望确保只有一行。当然，在这种情况下，理想的（理论上的）主键应该是没有列的主键，但我不知道有任何 SQL 产品可以让您声明它。
@Damien 您概述的场景是正确的，但我一直认为存储保证为一行的内容（如配置或设置信息）是关系数据库的混蛋。当您可以将信息存储在其他地方时，为什么要创建一个表并产生从该表中提取单个记录的开销？
@Shakti，根据定义限制为只有一行的表确实有一个键 - 键是空的（一组空的属性）。只是你不能直接用 SQL 的 PRIMARY KEY 约束来指定。 PRIMARY KEY != 主键 :)

【解决方案1】：

是的。

如果您有一个始终会完全获取的表，并且被零个其他表引用，例如某种独立设置或配置表，那么拥有主键和参数是没有意义的有些人可能会认为，在这种情况下添加 PK 会欺骗正常使用此类表。

这是罕见的，并且可能在最常见的情况下这样做是错误地，但它们确实存在，并且这样的实例可能是有效的。

【讨论】：

为什么要在这样的表中重复行？当您说您永远不想“获取”单个行时，这是否意味着您永远不想更新它们并且您会为每次更改数据替换每一行？还是说数据是只读的？
@dportas：你说的一切。 unique 是一种防止重复行的方法。没有 PK 是一种表示永远不应从另一个表引用此表的方法。最常见的用例（通常无密钥表非常少见）是经典的单记录设置表。我不认为省略定义 PK 是好，但要求每个表都必须有一个是错误的。如果是这样，我们就别无选择了。
@crjh：同意“主”键总是多余的。我对您的回答的解释是您的意思是“根本没有钥匙”。如果您的意思是：“一张表应该至少有一个候选键，其中一个可能被称为主键，也可能不被称为主键”，那么我同意。限制为一行的表也不例外，因为它隐含地确实有一个（空）键。
@dportas：当然，我认为我们在同一页面上。

【解决方案2】：

没有。

主键在幕后做了很多事情，即使您的应用程序从不使用它。

例如：clustering 提高效率（因为heap tables 是一团糟）。

更不用说，如果有人必须在您的表上做某事，需要拉出特定的行并且您没有主键，那么您就是坏人。

【讨论】：

【解决方案3】：

什么是主键/唯一键？

在关系数据库设计中，唯一键可以唯一标识表中的每一行，与超键概念密切相关。唯一键由单个列或一组列组成。如果不使用 NULL 值，则表中的两个不同行在这些列中不能具有相同的值（或值的组合）。根据其设计，一个表可能有任意多个唯一键，但最多有一个主键。

因此，当您不必区分（唯一标识）每一行时，
你不必使用主键

例如，用于日志的大表，
在不使用主键的情况下，您可以拥有相当小的数据量和更快的插入速度

【讨论】：

【解决方案4】：

主键不是强制性的，但创建没有主键的表不是一个好习惯。 DBMS 在 PK 上创建自动索引，但您可以使列唯一并对其进行索引，例如users 表中的user_name 列通常是唯一的和索引的，所以你可以选择跳过这里的PK。但这仍然是个坏主意，因为 PK 可以用作参照完整性的外键。

一般来说，您应该几乎总是在表格中包含 PK，除非您有充分的理由证明没有 PK 是正当的。

链接表（在多对多关系中）可能没有主键。但是，我个人也喜欢在这些表中进行 PK。

【讨论】：