0

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

该数据库也没有实现 FK。

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

4

6 回答 6

2

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

很好的理由是：

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

不好的原因是无限的:-)

实际上导致缺少主键的最常见的错误原因是，当 DB 由具有很少或没有 DB 经验的应用程序/代码开发人员设计时，他们想要（或认为他们应该）处理应用程序中的所有数据约束.

于 2012-11-16T07:00:01.467 回答
2

我认为 PK 对于几乎所有情况都是强制性的。会有很多原因存在，但我会处理其中的一些。

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

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

于 2012-11-16T04:46:28.373 回答
1

有什么正当理由吗？我会说“不”——我是一名数据库专家——但有些地方坚持将数据库用作愚蠢的数据存储。它们通常在应用程序代码中实现所有完整性“约束”。

将完整性约束放入应用程序代码通常不是为了提高性能。事实上，如果您构建了一个执行所有已知约束的数据库，而您构建了另一个仅在应用程序代码中具有功能相同约束的数据库，那么第一个几乎肯定会围绕第二个运行。

相反，应用程序级别的约束通常希望增加灵活性。（而且，在这个过程中，一些已知的约束通常会被删除，这似乎可以提高性能。）如果为了批量加载一些肮脏的数据而强制执行某些约束变得不方便，应用程序程序员可以回避应用程序-level 约束一段时间，然后在更方便的时候清理数据。

于 2012-11-16T06:28:20.343 回答
0

我不是数据库专家，但我记得与一位在 Oracle 应用部门工作的朋友的对话。谁告诉我这样做是为了处理紧急情况。如果在生成的某些报告中存在问题，您可以通过连续放置来解决，那么数据库级别的约束通常会妨碍您。他们通常在应用程序而不是数据库中实现诸如唯一主键之类的东西。它效率低下，但对他们来说已经足够了，而且在灾难恢复情况下更易于管理。

于 2012-11-16T04:43:17.360 回答
0

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

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

想到的一个例子是日志表，它只记录一些数据（从不更新或查询单个记录）。

于 2012-11-16T04:44:25.853 回答
0

插入带有索引的表时会产生少量开销，如果您有主键，则需要索引。当然，缺点是查找一行的成本非常高。

于 2012-11-16T04:45:05.273 回答