DB Fk/Pk密钥性能

问题描述:

在我们的数据库中,我们有一个具有数百万行不断插入和更新的单中心表。 此表具有一个充当唯一标识符的列,用于将此表的内容与具有一对多关系的多表链接起来。DB Fk/Pk密钥性能

这意味着,在同一事务中插入条目,例如USERS表时,USERS_PETS和USERS_PARENTS(以及更多)将填充多行,基于主表中的唯一标识符。由于使用此DB的应用程序不断插入新条目并更新现有条目,因此这些表之间的关系仅保留在应用程序级别(即逻辑ERD,而不是通过FK/PK减量来处理)。

问题:

  1. 这是正确的假设,但从纯performnces点,这是最好的办法?
  2. 有没有一种方法来设置这些键(以便数据库将更具自我描述性),而不影响性能?
+2

我会**从来没有**放弃数据完整性(PK/FK关系)只是为了表现... – 2011-02-18 16:21:06

+0

为了使任何有用的陈述,你需要更具体的数据库你正在使用的系统(和版本),以及那些表和键是什么样的...... – 2011-02-18 16:26:14

+0

谢谢马克。如果客户不会拿走你的软件,并且因为速度不够快而没有客户,那该怎么办?软件方面,我们同时使用DB2和Oracle(11g),因此我正在寻找一种全面的洞察力而不是特定的解决方案。 – 2011-02-18 20:33:31

  1. 不,因为同样的原因,即使我们匆忙,我们也会在汽车上使用安全带。差异是可以忽略的,完全不值得。
  2. 一些特定的dbms供应商可能会提供一种声明约束但不强制执行的方法。例如,在Oracle中,可以将完整性约束状态指定为DISABLE NOVALIDATE

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

基于希望的数据完整性。希望不能很好地扩展。

而且没有“纯粹的性能角度”这样的东西。除非,也就是说,你从不从数据库读取数据。如果您只插入,绝不更新,永不删除,并且从不读取,您可以提出存在“纯粹的性能观点”的情况。但是,如果您更新,删除或读取,那么性能不是重点 - 它更像是一个表面或一个固体,你所能做的就是在插入,更新,删除和移动平衡点读取。

而且,因为有人读这仍然不会得到它的最关键部分内容表现越来越背面正确答案。如果你不能保证正确的答案,明智的人会不在意你的插入速度有多快。