强规范化的关系数据库效率不高吗？

Question

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

应如何找到正确的妥协方案？

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

Answer 1

它是加速还是降低速度取决于数据的性质，表的大小，查询的类型，索引。我已经看到它有两种方式，但是，根据我的经验，对第三种正常形式的标准化会加速。构建关系数据库以进行规范化和设计，以便满足这些需求。

非规范化倡导者经常忘记的一件事是速度对交易至关重要（可能由于阻塞潜力而更为关键），而非规范化通常会减慢更新速度。您无法仅根据select语句来衡量性能。非规范化数据库表通常更宽，更宽的表通常也会导致速度减慢。

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

如果您没有设计数据仓库，请规范化您的数据。除非您是具有至少5年大型系统经验的数据库专家，否则永远不要反规范化。如果你不知道自己在做什么，你可能会伤害到很多东西。如果事情缓慢，则非规范化是最后一次尝试的性能改进之一。一般来说，问题是通过编写更好的查询来解决的，这些查询是可以搜索的，并且不会使用性能较差的技术（如相关子查询）或者应用正确的索引。

Answer 2

规范化可优化存储要求和数据一致性。作为权衡，它可以使查询更复杂和缓慢。

  

应如何找到正确的妥协方案？

不幸的是，这不能用普遍性来回答。

这一切都取决于您的应用及其要求。

如果您的查询运行速度太慢，索引或缓存或查询重写或数据库参数调整没有削减它，则非规范化可能适合您。

（OTOH，如果您的查询运行得很好，或者可以运行得很好，可能没有必要去那里）。

Answer 3

这取决于。每当我努力规范化数据库时，它都会从根本上加速。但是，非规范化DB的性能问题是它们需要许多索引，其中大部分都没有用于任何特定查询，列数太多，对标准化数据库不需要的查询强制使用DISTINCT约束，以及低效的表格搜索。

如果常见查询需要在大型表上执行许多连接以进行最简单的查找，或者在多个表中执行写操作以更新用户/应用程序所看到的单个实体的原子更新，那么随着流量的增长，这种负担，高于低/无正常化的速度。通常情况下，一切都运行正常，直到数据库和应用程序放在不同的生产服务器上，而它们位于同一个开发服务器上，或者当数据大到足以开始一直打到磁盘时。

DBMS产品将逻辑布局和物理存储耦合在一起，因此尽管可能会像降低速度一样提高速度，但基表的规范化在某种程度上会影响系统的性能。

通常，正确的妥协是具有SQL DBMS的视图。如果您通过合同使用任何设计变体，即使不考虑规范化或性能，视图也可能是正确的设计决策，因此应用程序可以获得满足其需求的模型。与主要网站一样，可扩展性问题在这个时间点产生了没有快速简便解决方案的问题。

Answer 4

除了Thilo的帖子： 由于db对数据本身进行规范化，因此SAP HANA上的规范化是错误的。如果你这样做，你会减慢数据库的速度。