DB Fk/Pk 键性能答案

【问题标题】：DB Fk/Pk keys performanceDB Fk/Pk 键性能
【发布时间】：2011-02-19 04:31:07
【问题描述】：

在我们的数据库中，我们有一个中心表，其中包含数百万行不断插入和更新。该表有一个列作为唯一标识符，用于将该表的内容与具有一对多关系的多个表链接起来。

这意味着我们在同一个事务中向 USERS 表插入条目时，还将根据主表中的相同唯一标识符填充多行 USERS_PETS 和 USERS_PARENTS（以及更多行）。

由于使用此数据库的应用程序不断插入新条目并更新现有条目，因此这些表之间的关系仅保留在应用程序级别（即逻辑 ERD，而不是通过 FK/PK 减速处理）。

问题：

从纯粹的性能角度假设这是最好的方法是否正确？
有没有办法在不影响性能的情况下设置这些键（以便 DB 更具自我描述性）？

【问题讨论】：

我永远不会仅仅为了性能而放弃数据完整性（PK/FK 关系）......
为了获得任何有用的语句，您需要更具体地了解您正在使用的数据库系统（和版本），以及这些表和键是什么样的.....
谢谢。如果客户端不接受您的软件，而您因为运行速度不够快而没有客户端怎么办？软件方面，我们同时使用 DB2 和 Oracle (11g)，所以我正在寻找一般的见解而不是具体的解决方案。

标签： database database-design architecture erd

【解决方案1】：

这是最糟糕的方法，我保证您最终会遇到数据完整性问题。数据完整性远比性能更重要。这是愚蠢和短视的。

【讨论】：

也许我可以更圆滑一些，但这样的事情让我很生气。
别这样——很好非常清楚这些优先事项！
+1 - 我们需要坚持正确的规范化原则，尤其令人讨厌的是那些到处宣称这些事情以任何方式都可以接受的人。
+1 表示“愚蠢和短视”。如果不需要返回正确的答案，我可以让大多数数据库真正快速运行。
我是一个新来的应用程序运行超过 6 年。软件中没有数据完整性问题，因为它是在应用程序逻辑中处理的。但另一方面，您对 tis 的强烈看法非常受欢迎。

【解决方案2】：

不，出于同样的原因，即使我们赶时间，我们也会在汽车中使用安全带。差异可以忽略不计，完全不值得。
某些特定的 dbms 供应商可能会提供一种声明约束而不强制执行约束的方法。例如，在 Oracle 中，您可以将完整性约束状态指定为 DISABLE NOVALIDATE。

【讨论】：

【解决方案3】：

您将数据完整性建立在希望之上。希望不能很好地扩展。

而且没有“纯粹的性能观点”这样的东西。除非，也就是说，您从未从数据库中读取过数据。如果只插入、从不更新、从不删除、从不读取，则可以证明存在“纯性能观点”。但是，如果您曾经更新、删除或读取，那么性能就不是重点了——它更像是一个表面或一个实体，您所能做的就是在插入之间移动平衡点，更新、删除和读取。

而且，因为阅读本文的人仍然无法理解，阅读性能的最关键部分是找回正确答案 .如果您不能保证正确答案，明智的人不会关心您的插入速度有多快。

【讨论】：