我正在阅读这个问题https://meta.stackexchange.com/questions/26398/stackoverflow-database-design-join-issues，我得到了以下问题：使用非常规范化的数据库效率不高？
应该如何找到正确的折衷方案？
我不确定这个问题是否更适合这里或程序员。这里有一些类似的，但如果我要搬家，请问我。
【问题讨论】：
标签： database performance normalization
它会加快还是减慢速度在很大程度上取决于数据的性质、表的大小、查询的类型和索引。我已经看到它是双向的，尽管根据我的经验，标准化到第三范式通常会加快速度。关系数据库的构建是为了规范化和设计，以便这些事情是预期的。
非规范化倡导者经常忘记的一件事是，速度对事务至关重要（由于潜在的阻塞可能更重要），并且非规范化通常会减慢更新速度。您不能仅根据 select 语句来衡量性能。非规范化的数据库表通常更宽，更宽的表通常也会导致速度变慢。
非规范化数据库是保持数据完整性的主要问题，并且在规范化数据库中更改公司名称可能会导致需要更新一条记录，而在非规范化数据库中可能会导致需要更新 100,000,000 条记录。这就是为什么非规范化通常仅适用于通过 ETL 过程加载数据但经常查询数据库本身以用于复杂报告场景的数据库（如数据仓库）。如果至少将它们标准化为第三范式，则具有大量用户更新、删除和插入的事务数据库通常会快得多。现在你也可以对规范化发疯了，不要误会我的意思。我不应该加入 10 张桌子来获得一个简单的地址，尤其是如果我经常得到它们的话。经常一起使用的数据通常属于一起，特别是如果进行更改时项目不太可能更改一百万条记录。例如，在地址中，如果芝加哥将其名称更改为新芝加哥，则需要进行大量更新，但在我所在的地区，这种大规模的地址更改非常罕见。另一方面，公司名称更改很频繁，如果需要对数百万条非规范化记录进行更改，可能会导致大规模中断。
如果您不是在设计数据仓库，请规范化您的数据。除非您是具有至少 5 年大型系统经验的数据库专家，否则切勿进行非规范化。如果你不知道自己在做什么，你会极大地伤害事情。如果事情进展缓慢，非规范化是最后一次尝试的性能改进之一。通常，通过编写更好的查询来解决问题，这些查询是可搜索的，并且不使用性能不佳的技术（如相关子查询）或应用正确的索引。
【讨论】：
这取决于。每次我对数据库进行规范化时，它都会从根本上加速。但是，非规范化数据库的性能问题是它们需要许多索引，其中大多数不用于任何特定查询，具有太多列，强制 DISTINCT 约束对规范化数据库不需要的查询进行约束，以及低效的表搜索。
如果常见查询需要在大型表上执行许多连接以进行最简单的查找，或者访问多个表以进行写入以更新用户/应用程序视为单个实体的原子更新，那么随着流量的增长，将该负担的比率高于较低/未标准化的情况。通常情况下，一切运行正常，直到数据库和应用程序放在不同的生产服务器上，而它们在同一个开发服务器上，或者当数据变得足够大以开始一直访问磁盘时。
DBMS 产品将逻辑布局和物理存储结合在一起，因此虽然速度可能会提高或降低速度，但基表的规范化会在某种程度上影响系统的性能。
通常，正确的折衷方案是使用 SQL DBMS 的视图。如果您使用合同设计的任何变体，即使不考虑规范化或性能，视图也可能是正确的设计决策，以便应用程序获得适合其需求的模型。可扩展性问题（例如主要网站）会造成目前没有快速简便的解决方案的问题。
【讨论】：
除了 Thilo 的帖子： 由于 db 对数据本身进行了规范化，因此对 SAP HANA 进行规范化是错误的。如果你仍然这样做，你会减慢数据库的速度。
【讨论】：
规范化优化了存储要求和数据一致性。作为一种权衡，它会使查询变得更加复杂和缓慢。
应该如何找到正确的折衷方案？
很遗憾，这无法笼统地回答。
这完全取决于您的应用程序及其要求。
如果您的查询运行速度太慢，而索引或缓存或查询重写或数据库参数调整无法解决问题，那么非规范化可能适合您。
（OTOH，如果您的查询运行良好，或者可以使其运行良好，则可能不需要去那里）。
【讨论】：