为什么没有主键

Question

我继承了一个包含缺少主键的表的数据库。这是一个OLTP数据库。其中一个表有大约300k的记录，并且没有实现主键，即使检查模式的其余部分告诉我一个列被用作主键，即在另一个表中复制，具有相同的名称等。即。这不是“行尾”表

此数据库也不实现FK。

我的问题是 - 表中是否有任何正当理由（在Oracle中）没有主键？

Answer 1

我认为PK几乎适用于所有情况。会有很多原因，但我会对其中的一些进行处理。

• 阻止插入重复的行
• 行将被引用，因此它必须有一个键

我看到很少有情况下没有PK的表（例如日志表）。

Answer 2

不是特定于甲骨文，但我记得读到一个这样的用例，其中mysql高度为大坝（发电）项目定制，我想。来自传感器的输入数据的顺序为每秒100-1000或者其他。他们为每条记录使用时间戳，因此不需要主键（如此处另一个答案中提到的日志/日志记录）。

所以好的原因是：

• 在高频交易的情况下的开销
• 在这种情况下的必要性或不必要性
• “唯一性”由应用程序维护或推断，而不是由db
维护或推断
• 在规范化表中，如果每个记录都需要是唯一的，并且每个字段都在其他表中引用，那么拥有PK还会增加索引开销，如果PK实际上永远不会在任何SQL查询中使用（imho，I不同意这一点，但这是可能的）。但它仍然应该包含所有字段的unique索引。

不好的理由是无限的： - ）

最常见的错误原因导致缺少主键的原因是数据库是由应用程序/代码开发人员设计的，几乎没有数据库经验，谁想（或认为他们应该）处理应用程序中的所有数据约束。

Answer 3

任何有效的原因？我会说“不” - 我是一个数据库人 - 但有些地方坚持使用数据库作为一个哑数据存储。它们通常在应用程序代码中实现所有完整性“约束”。

通常不会将完整性约束放入应用程序代码中以提高性能。事实上，如果你构建了一个强制执行所有已知约束的数据库，并且只在应用程序代码中构建了另一个具有功能相同约束的数据库，那么第一个几乎肯定会在第二个约束下运行环。

相反，应用程序级约束通常希望增加灵活性。 （并且，在此过程中，一些已知的约束通常被删除，出现以提高性能。）如果为了批量加载某些邋data数据而强制执行某些约束变得不方便，那么应用程序员可以稍微调整一下应用程序级别的约束，然后在更方便的时候清理数据。

Answer 4

我不是数据库专家，但我记得与在Oracle应用部门工作的朋友的对话。谁告诉我这是为了处理紧急情况。如果生成的某个报告中存在问题，您可以通过连续修复​​，db级别约束通常会阻碍您。它们通常在应用程序而不是数据库中实现诸如唯一主键之类的东西。对于灾难恢复方案而言，它效率低但足够且更易于管理。

Answer 5

您需要一个主键来强制其列的一个子集的唯一性（如果您需要引用各个行，则非常有用）。由于与之关联的索引，它还加速了某些查询。

如果您不需要该索引或该唯一性约束，那么您可能不需要主键（索引不是免费的）。

我们想到的一个例子是记录表，它只记录一些数据（永远不会更新或查询单个记录）。

Answer 6

插入带索引的表时开销很小，如果有主键则需要索引。当然，缺点是找到一排是非常昂贵的。