database - 强规范化关系数据库效率不高？

Question

我正在阅读这个问题 https://meta.stackexchange.com/questions/26398/stackoverflow-database-design-join-issues我得到了以下问题:使用非常规范化的数据库效率不高？

应该如何找到正确的折衷方案？

我不确定这个问题更适合这里还是程序员。这里有一些类似的，但如果我应该移动，请问我。

Answer 1

它会加快还是减慢它在很大程度上取决于数据的性质、表的大小、查询类型和索引。我已经看到它是双向的，尽管根据我的经验，标准化到第三范式通常会加快速度。关系数据库的构建是为了规范化和设计，以便这些事情是预期的。

反规范化提倡者经常忘记的一件事是，速度对事务至关重要(由于潜在的阻塞可能更为关键)并且反规范化通常会减慢更新速度。您不能仅根据 select 语句来衡量性能。非规范化数据库表通常更宽，而更宽的表通常也会导致速度下降。

非规范化数据库是保持数据完整性的主要问题，在规范化数据库中更改公司名称可能会导致需要更新一条记录，而在非规范化数据库中可能会导致 100,000,000 条记录需要更新。这就是为什么非规范化通常只适用于通过 ETL 过程加载数据但数据库本身经常查询复杂报告场景的数据库(如数据仓库)。如果至少将它们规范化为第三范式，则具有大量用户更新、删除和插入的事务性数据库通常要快得多。现在你也可以疯狂地进行标准化，不要误会我的意思。我不应该加入 10 个表来获得一个简单的地址，特别是如果我经常得到它们的话。经常一起使用的数据通常属于一起，特别是如果这些项目在进行更改时不太可能更改一百万条记录。例如，在地址方面，如果芝加哥将其名称更改为新芝加哥，则需要进行大量更新，但这种类型的大规模地址更改在我所在的地区非常罕见。另一方面，公司名称更改频繁，如果需要对数百万条非规范化记录进行更改，可能会造成大规模中断。

如果您不是在设计数据仓库，那么请规范化您的数据。除非您是具有至少 5 年大型系统经验的数据库专家，否则永远不要反规范化。如果您不知道自己在做什么，您可能会极大地伤害事物。如果事情进展缓慢，非规范化是最后尝试的性能改进之一。通常，通过编写更好的可优化查询并且不使用相关子查询等性能不佳的技术或应用正确的索引来解决问题。