如果一个表有许多(20+外键)约束,这有什么缺点吗?

当您在子表中插入一行时,db引擎将查找父表中是否存在相应的值,这将占用一些cpu和一些逻辑读取。如果父表很小,则它们很可能在缓存中,因此,当手杖温度升高时,不会出现许多缓慢的物理读取。

更让我担心的是,如果您要从父表中删除:如果您的子表上没有相应的索引,则将锁定并扫描整个子表。另一方面,如果您的所有外键都有相应的索引,那么您的子表上可能会有多达20-30个额外的索引,这是一个相当大的减速。

你可能想运行自己的基准测试,然后自己看看。

与没有外键相比,只有一个外键会减慢插入/更新操作的速度,因为数据库必须检查外键值是否确实存在。拥有30个外键比没有外键要慢。
这就是说,究竟要慢多少取决于很多事情,包括您使用的值表/数据库引擎/索引/等等的大小…在最佳情况下几乎可以忽略不计。

是的,在检查所有相关约束时,插入和更新会有一些性能损失,但除非尝试以高速度插入数据,否则不太可能导致任何问题。数据的正确维护通常比快速维护更为重要,因此这种惩罚是值得的。

如果您对一些列执行更新,则只需要检查这些列上的约束,而大多数dbms将只检查这些约束。

当然,select语句不会慢下来,在某些情况下(可能很少见),优化器甚至可以从注意到正在连接的两个表之间的外键关系中获益。

在20-30个字段中,有多少很少被使用?也许可以再建一张桌子。使从编码的角度更新两个表变得更加困难,但是如果您可以省略大部分时间更新第二个表,则会加快速度。

我处理一个第三方应用程序的主表与相应的“自定义”表,我们可以设置我们自己的领域。不幸的是,我们一直使用“自定义”字段,很少能处理主表。

我认为这取决于你的查询是否使用了任何违禁品。如果查询由于某个约束而需要检查另一个表,则会看到性能受到影响。如果查询没有引用约束中的任何列,则性能影响可能可以忽略不计。

像大多数与数据库设计相关的东西一样,这取决于应用程序是否 重的 插入、更新和删除将遇到性能问题。在这种情况下,反规范化可能是合理的,尤其是在“值”表没有更改的情况下。