当我不需要主键时不使用主键可以吗答案

【问题标题】：Is it OK not to use a Primary Key When I don't Need one当我不需要主键时不使用主键可以吗
【发布时间】：2010-12-18 18:41:57
【问题描述】：

如果我不需要主键，我是否应该不向数据库添加主键？

【问题讨论】：

几乎没有不需要主键的情况。基本上，如果一个表没有主键，它就不是一个表——它只是一堆数据。
这可能与您的问题无关，但我确实需要问：您为什么不觉得自己需要一个？
您能否向我们提供有关您正在处理的情况的更多信息？主键并不总是必要的，但如果我们知道您想要做什么，我们可能会给您一些更好的建议。
您能否解释一下您认为您可能不需要 pkey 的原因？我真的想不出有什么理由忽略它。即使是单表数据模型也需要一个 pkey 来唯一标识一行。
我有 Murph 建议的日志表。当您有可能相同但同时发生的事件时（特别是如果使用 SMALLDATETIME），您使用什么作为主键，为什么？ PK 不是性能所必需的（聚集索引与 PK 没有任何关系），如果您也不需要查找任何内容......在这种情况下，我使用索引视图来提供聚合统计信息，但是我认为没有理由定义 PK。我同意，尽管在大多数情况下，您确实需要主键，而在大多数情况下，您认为不需要主键，但实际上确实需要。

标签： sql database-design primary-key normalization

【解决方案1】：

您确实需要一个主键。你只是还不知道。

【讨论】：

我曾经以为我也不需要主键...现在我知道了。
+1 因为这最准确地反映了现实。我可以看到一个人可能不需要一个但很少而且相差甚远的情况。
除非你不需要主键，而且你现在知道了。这是一个不寻常的案例。最好稳妥行事，宁可 PK。
我同意你的观点，但如果有人不同意你和我的观点，这个论点永远无法说服他们。

【解决方案2】：

主键唯一标识表中的一行。

它被索引和/或集群的事实是一个物理实现问题，与逻辑设计无关。

你需要一个让表格有意义。

【讨论】：

【解决方案3】：

如果您不需要主键，请不要使用主键。我通常需要主键，所以我通常使用它们。如果您有相关的表，您可能需要主键和外键。

【讨论】：

【解决方案4】：

是的，但只是在同样的意义上，如果您不打算发生事故，可以不系安全带。也就是说，当你需要它时，付出很小的代价就能获得很大的好处，即使你认为你不需要它，你也很有可能在未来会用到它。不同之处在于您更多需要主键而不是发生车祸。

您还应该知道，如果您不这样做，某些数据库系统会为您创建一个主键，因此您不会为引擎中发生的事情节省太多。

【讨论】：

我不同意。我拒绝系安全带，因为它们会阻止我完全享用我的啤酒。但是我永远不会创建没有 pk 的表。
@Rev Gonzo，您需要的是一个更具战略意义的啤酒架。来吧，现在是 2010 年。

【解决方案5】：

不，除非你能找到一个例子，“如果 table_x 没有主键，这个数据库会更好地工作。”

如果不需要性能、数据完整性和规范化，您可以主张永远不要使用主键。可能不需要安全性和备份/恢复功能，但最终，你穿上你的大男孩裤子，加入数据库实现的现实世界。

【讨论】：

【解决方案6】：

是的，一个表应该总是有一个主键...除非您不需要唯一地标识其中的记录。（我喜欢做绝对的陈述并立即反驳）

什么时候不需要唯一标识表中的记录？几乎从不。我以前做过审计日志表之类的事情。不会更新或删除的数据，也不会以任何方式受到限制。本质上是结构化的日志记录。

【讨论】：

【解决方案7】：

主键总是有助于提高查询性能。因此，如果您需要使用“键”来查询“外键”，或者用作查找，那么可以，创建一个外键。

【讨论】：

我不明白，主键有助于提高性能？如果您不需要它们，您将不会使用一个来查找记录。所以，没有任何好处。
那么该表将用于什么？大多数情况下，我们需要该表来存储一些信息，您将从中查找值。
Luke101 应该发布他的用例，我们会看到，如果他需要一个。

【解决方案8】：

我不知道。我使用了几个表，其中只有一行和一列。将始终只有一行和一列。没有外键关系。

我为什么要在上面放一个主键？

【讨论】：

您需要存储单条信息吗？类似于系统范围的偏好？每个人都需要那条数据，但您不希望仅仅为了获得那条数据而创建一个全新的东西。
啊。但是您确实需要此表上的主键。以及将主键限制为单个值的检查约束。因为否则你会在 6 个月后回来发现其他人为你添加了另一行，而你的应用程序选择哪一行是任意的......

【解决方案9】：

主键主要是正式定义的，以帮助参考完整性，但是如果表非常小，或者不太可能包含唯一数据，那么这是不必要的开销。在表上定义索引通常可用于暗示主键，而无需正式声明主键。但是，您应该考虑到定义主键对于开发人员和模式生成或 SQL 开发工具很有用，因为元数据有助于理解，并且一些工具依赖于此来正确定义模型中的主键/外键关系。

【讨论】：

【解决方案10】：

嗯……

关系数据库中的每个表都需要一个主键。如前所述，主键是唯一标识一条记录的数据...

如果您有一个连接 2 个不同表的 N-M 表，您可能会因为没有“ID”字段而侥幸，但您可以通过您连接的两个列的值来唯一地标识记录。（复合主键）

没有主键的表是违反第一范式的，与关系数据库无关

【讨论】：

【解决方案11】：

您应该始终有一个主键，即使它只是在 ID 上。也许 NoSQL 才是你所追求的（只是问）？

【讨论】：

【解决方案12】：

这在很大程度上取决于您能确定自己不需要。如果您有一点疑问，请添加一个 - 您稍后会感谢自己。一个指标是您存储的数据是否可能在某一时刻与数据库中的其他数据相关。

我能想到的一个用例是一种记录类型的表，您只需在其中逐个转储一个条目（以便以后正确处理它们）。如果您存储了足够的数据来过滤掉相关消息（如日期），您可能不需要主键。当然，为此使用 RDBMS 是有问题的。

【讨论】：