我们说我有一个表，其中有许多字段链接到其他“值表”的值。当然，我声明了每个外键的限制因素，以及它们是否能够实现完整性。
如果我最终得到的这些字段的数量在20-30范围内怎么办？它会以某种方式“减慢”表操作或不是真的吗？
ADDED：值表只有很少的记录，通常是5-10或者其他。该数据库是SQL Server 2008。
答案 0 :(得分：2)
当您在子表中插入一行时，如果父表中存在相应的值，则数据库引擎将查找 - 这将耗尽一些CPU和一些逻辑读取。如果你的父表很小，它们很可能都在缓存中，所以一旦你的手杖温暖，你就不会发现很多慢的物理读数。
如果您要从父表中删除，我会更关心的是：如果您没有在子表上有相应的索引，则将锁定并扫描整个子表。另一方面，如果您的所有外键都有相应的索引，那么您的子表上最多可能有20-30个附加索引，这是一个相当大的减速。
您可能想要运行自己的基准测试并亲眼看看。
答案 1 :(得分：1)
有一个外键减慢了插入/更新操作而没有外键 - 只是因为数据库必须检查外键值是否确实存在。有30个外键会比没有外键慢。
也就是说，它会变慢多少取决于许多因素，包括您正在使用的值表/数据库引擎的大小/索引/等等......在最佳情况下可能几乎可以忽略不计。
答案 2 :(得分：1)
是的，由于检查了所有相关约束，因此插入和更新会有一些性能损失，但除非您尝试以高速率插入数据，否则不会引起任何问题。通常更重要的是要正确维护数据而不是快速维护，因此罚款是非常值得的。
如果执行几列的UPDATE，则只需要检查这些列的约束，并且大多数DBMS只会检查这些约束。
SELECT语句当然不会慢下来，并且在一些（可能很少见的）情况下甚至可以从优化器知道正在连接的两个表之间的外键关系中受益。
答案 3 :(得分：0)
在20-30个字段中，有多少很少使用？也许可以建立一些其他表。从编码角度更新两个表变得更加困难，但如果你可以在大多数时间省略更新第二个表，那么会加快速度。
我处理第三方应用程序，其主表与相应的“自定义”表格，我们可以设置自己的字段。不幸的是，我们一直使用“自定义”字段，很少只能处理主表。
答案 4 :(得分：0)
我认为这将取决于您的查询是否使用任何约束。如果您的查询由于约束而需要检查另一个表，那么您将看到性能损失。如果您的查询未引用约束中的任何列，则性能命中率可能会忽略不计。
答案 5 :(得分：0)
像大多数数据库设计相关，这都取决于。如果您的应用程序重插入，更新和删除，您将遇到性能问题。这可能是一种可以证明去标准化的情况，特别是如果“价值”表没有变化。