使用规范化表真的更好吗？答案

【问题标题】：Is it really better to use normalized tables?使用规范化表真的更好吗？
【发布时间】：2010-10-07 02:38:21
【问题描述】：

我听我的团队负责人说，在过去的一些项目中，他们不得不取消规范化以加快查询速度。

我认为这可能与表联合有关。

精简表真的比胖表少吗？

【问题讨论】：

标签： sql-server database oracle normalization

【解决方案1】：

这取决于...加入表本质上比拥有一个“预加入”的大表（即去规范化）要慢。但是，通过非规范化，您将创建数据重复，并且您的表将变得更大。规范化被视为一件好事，因为它创建了可以回答“任何”问题的数据库，如果正确完成，您可以构建一个选择来获取您的数据。在某些其他形式的 DB 中情况并非如此，而那些现在（大部分）是历史上的不相关，规范化/关系 DB 赢得了这场战斗。

回到您的问题，使用反规范化使事情变得更快是一种被广泛接受的技术。通常最好运行您的数据库一段时间，这样您就知道要反规范化什么以及不理会什么，并且将数据保留为“正确”的规范化形式并将数据拉入一组反规范化报告中也很常见定期表。如果该过程作为报表运行的一部分完成，那么数据也始终是最新的。

作为过度规范化的一个例子，我在过去看到过数据库，其中一周中的几天和一年中的几个月被拉到单独的表中 - 日期本身被规范化 - 你可能走得太远了。

【讨论】：

【解决方案2】：

您应该研究一下OLTP（在线事务处理）和OLAP（在线分析处理）数据库之间的区别。

简而言之，主要关注记录事务 (OLTP) 的数据库系统通常以更规范化的方式构建，减少数据重复并简化记录的创建和更新，但以优化数据检索为代价。

更关注数据检索和分析 (OLAP) 的数据库系统通常以不太规范化的方式构建，牺牲数据存储优化以最大限度地提高查询和分析速度。

Database normalization 和 Denormalization 是这种权衡的核心。

【讨论】：

强调一下，如果你去规范化，你会重复数据，这意味着更新数据必须更新更多行，这会更慢。

【解决方案3】：

Jeff wrote about this，随后进行了激烈的讨论。它也是关于 SO 的大量讨论的主题，例如whats the better database design more tables or more columns。正如其他人所指出的，使用常识并且不要过度规范化。

【讨论】：

【解决方案4】：

根据我长期使用 Oracle OLTP 数据库的经验，其中一些数据库非常庞大且繁忙，老实说，我不记得曾经遇到过真正意义上的“非规范化性能”的案例必需的。然而，我看到很多情况下，有人提前决定应该应用非规范化，因为他们担心、不确定和怀疑潜在的性能问题。这通常是在没有任何基准测试的情况下完成的，而且我总是发现实际上并没有实现任何性能改进——但是数据维护代码变得比原来要复杂得多。

OLAP 是一种非常不同的动物，我无法对此发表评论。

【讨论】：

【解决方案5】：

这个问题经常重复出现。主要原因是 SQL 作为最流行的数据库语言，其所有最流行的实现都将逻辑表设计与物理表设计混为一谈。

永恒的答案是你应该始终规范化你的逻辑表，但实际的答案是复杂的，因为在现有 SQL 实现下实现某些优化的唯一方法是非规范化你的物理表设计（本身不是坏事) 在这些实现中，需要非规范化您的逻辑表设计。

简而言之，这取决于。有时非规范化对性能很重要，但就像其他所有与性能相关的事情一样，在考虑采用这条路线之前，您应该测量、测量、测量。

【讨论】：

【解决方案6】：

性能与在 RDBMS 上完成的标准化量成反比。话虽如此，表格越正常，出错的可能性就越小。非规范化可能会损害 RDBMS 的性能，即所有数据都保存在一个表中。

【讨论】：

性能与规范化的数量不成反比，在规范化的系统中，数据的更新和插入速度更快。

【解决方案7】：

众所周知，规范化会损害性能的原因是连接相当昂贵。如果表 X 中有 N 条记录，表 Y 中有 M 条记录，则 X 和 Y 的连接会创建一个包含多达 N*M 条记录的临时表。尽管数据库使用了一些优化技巧来在不需要时不生成整个表，但它仍然必须处理所有记录。

非规范化是将经常使用的数据放在一个表中以提高性能的过程，以提高数据库的纯度。大多数人认为这是一种可接受的交易，甚至故意设计非规范化的架构以跳过中间步骤。

【讨论】：