database - DB 设计和性能：使用冗余 FK 来提高性能是否可行？

Question

假设我有以下数据库结构：

并且我的应用程序需要显示包含所有详细信息（型号、产品系列、品牌、生产商）的文章列表。为此，我需要进行更多的 JOIN 以获得所需的数据。

如果我通过为 Article 表创建冗余 FK 来提高应用程序的性能，是否可以，如下所示？它真的提高了性能吗？

Answer 1

是的，如果您不想检索层次结构中“中间”对象的任何数据，您可以通过这种方式提高性能。这是一种常见的非规范化形式。请注意，您需要小心不要让不一致的地方溜进来。

我通常会设置一个夜间任务来验证非规范化数据，将错误发送给我并自动修复它们。这并不难做到，并且消除了一类令人讨厌的错误。

人们这样做的另一个原因是将所有表分区在同一个键上。

Answer 2

找出设计是否提高性能的最佳方法是尝试它；第二种最好的方法是仔细考虑您可能需要运行的查询，然后尝试在您的脑海中对它们进行建模。如果不知道您要运行什么查询，或者您的数据库有多大，就很难知道您是否会看到性能改进。

笼统地说，除非你有一个非常大的数据库（假设你在体面的硬件上运行它，并且你已经调整了索引），否则你不会看到对性能的可衡量的影响。通过“非常大”，我认为几个表中有数百万行。

如果你真的需要去规范化，我的建议是创建一个显式去规范化的表，而不是用冗余键“污染”你的常规设计。理解一个单独的“应该如何”和“妥协”的设计要容易得多，而不是将两者混合在一起。

为了实现这一点，我会创建一个单独的表 - 也许是“cached_articles”，其中包含列：

article_id
...(article data)
model_id
....(model data)
family_id
...(family data)
brand_id
....(brand data)
producer_id
....(producer data)

您可以通过批处理作业或触发器来维护此表。您应该只让您的应用程序代码写入规范化表，并且只在需要时从缓存表中读取。

您还应该建立一个强大的“一致性检查”机制来识别可能导致应用程序崩溃的数据问题；一旦您的数据库增长到需要这种设计的大小，这些一致性检查就会变得很重要，因为它们会遇到相同的性能问题......