是否应该对 OLAP 数据库进行非规范化以提高读取性能？

Question

Closed. This question is opinion-based. It is not currently accepting answers.

---

想要改进这个问题？更新问题，以便可以通过编辑这篇文章用事实和引文来回答它。

4 年前已关闭。

Answer 1

神话

我一直认为数据库应该非规范化以供读取，就像 OLAP 数据库设计所做的那样，而不是进一步夸大 OLTP 设计的 3NF。

对此有一个神话。在关系数据库上下文中，我重新实现了六个非常大的所谓“非规范化”“数据库”；并执行了八十多项任务来纠正他人的问题，只需将其规范化、应用标准和工程原理即可。我从未见过任何证据证明这个神话。只有人们重复这个咒语，就好像这是某种神奇的祈祷一样。

标准化与非标准化

（“非标准化”是一个欺诈性术语，我拒绝使用它。）

这是一个科学行业（至少是提供不会破坏的软件的部分；这让人们在月球上；运行银行系统等）。它受物理定律支配，而不是魔法。计算机和软件都是有限的、有形的、受物理定律约束的物理对象。根据我接受的中学和高等教育：

• 比一个更小、更薄、组织性更强的物体表现得更好。

• 标准化会产生更多的表，是的，但每个表要小得多。尽管有更多的表，但实际上 (a) 连接更少，并且 (b) 连接速度更快，因为集合更小。总体上需要更少的索引，因为每个较小的表需要更少的索引。规范化表还会产生更短的行大小。

• 对于任何给定的资源集，规范化表：

  • 在相同的页面大小中容纳更多行
  • 因此可以将更多行放入同一缓存空间，从而提高整体吞吐量）
  • 因此可以在相同的磁盘空间中容纳更多的行，从而减少 I/O 的数量；当需要 I/O 时，每个 I/O 的效率更高。
    。
• 大量重复的对象不可能比存储为单一事实版本的对象表现得更好。例如。当我删除表和列级别的 5 倍重复时，所有事务的大小都减小了；锁定减少；更新异常消失了。这大大减少了争用，从而增加了并发使用。

因此，总体结果是性能高得多。

根据我的经验，从同一个数据库提供 OLTP 和 OLAP，从来不需要“去规范化”我的规范化结构，以获得更高的只读 (OLAP) 查询速度。这也是一个神话。

• 不，其他人要求的“非规范化”降低了速度，并且被消除了。我并不感到惊讶，但请求者再次感到惊讶。

人们写了很多书，兜售神话。需要认识到，这些人都是非技术人员；既然他们在推销魔法，那么他们推销的魔法就没有科学依据，而且他们在推销时很容易回避物理定律。

（对于任何想质疑上述物理科学的人，仅仅重复咒语是没有任何效果的，请提供支持咒语的具体证据。）

为什么这个神话普遍存在？

嗯，首先，它是在不寻求克服物理定律的方法的科学类型中并不普遍。

根据我的经验，我确定了这种流行的三个主要原因：

1. 对于那些无法标准化数据的人来说，这是不这样做的一个方便的理由。他们可以参考魔法书，在没有任何魔法证据的情况下，他们可以虔诚地说“看到一位著名作家验证了我所做的事情”。最准确地说，尚未完成。

2. 许多 SQL 编码人员只能编写简单的单级 SQL。规范化结构需要一定的 SQL 功能。如果他们没有那个；如果他们无法在不使用临时表的情况下生成 SELECT；如果他们不能编写子查询，他们就会在心理上坚持使用他们可以处理的平面文件（这就是“非规范化”结构）。

3. 人们喜欢读书和讨论理论。没有经验。尤其是魔法。它是一种补品，是实际经验的替代品。任何真正正确规范化数据库的人都从未说过“非规范化比规范化更快”。对于任何说出咒语的人，我只是说“给我证据”，但他们从未拿出任何证据。所以现实是，人们出于这些原因重复神话，没有任何正常化的经验。我们是群居动物，未知是我们最大的恐惧之一。

   这就是为什么我总是在任何项目中包含“高级”SQL 和指导。

我的答案

如果我回答了您问题的每个部分，或者我回答了其他一些答案中的错误元素，那么这个答案将会长得离谱。例如。上面只回答了一项。因此，我将全面回答您的问题，而不涉及具体组成部分，并采取不同的方法。我只会涉及与你的问题相关的科学，我有资格并且非常有经验。

让我以易于管理的方式向您介绍科学。

六大大规模全面实施任务的典型模型。

• 这些是小公司中常见的封闭“数据库”，而这些组织是大型银行，
• 对于第一代“让应用程序运行的心态”来说非常好，但在性能、完整性和质量方面完全失败，
• 它们的设计对于每个应用程序，单独
• 报告是不可能的，他们只能通过每个应用程序进行报告
• ，因为“非标准化”是一个神话，准确的技术定义是，它们非标准化
  • 为了“去规范化”，必须首先规范化；然后稍微扭转这个过程
    在人们向我展示他们的“非规范化”数据模型的每一个例子中，简单的事实是，它们根本没有规范化；所以“去规范化”是不可能的；它只是未标准化
• 因为他们没有太多的关系技术，或者数据库的结构和控制，但它们被冒充为“数据库”，我将这些词放在引号中，
• 因为对于非规范化结构是科学保证的，他们遭受了多个版本的事实（数据重复），因此存在高争用和低并发性，在每个版本中，
• “数据库”中都存在额外的数据重复问题
• 他们在组织试图保留的 所有这些重复项都是同步的，因此他们实现了复制；这当然意味着需要一台额外的服务器；待开发的ETL和同步脚本；并维护；等等
• ，不用说，同步永远不够，他们总是
• 用所有的争用和低吞吐量来改变它，为每个“数据库”证明一个单独的服务器是没有问题的。这并没有多大帮助。

所以我们思考了物理定律，并应用了一些科学知识。

我们实施了标准概念，即数据属于公司（而不是部门），而公司想要一个版本的事实。该数据库是纯关系型数据库，标准化为 5NF。纯开放架构，任何应用程序或报表工具都可以访问它。存储过程中的所有事务（而不是遍布网络的不受控制的 SQL 字符串）。经过我们的“高级”教育后，每个应用程序的相同开发人员都对新应用程序进行了编码。

显然，科学是有效的。嗯，这不是我的私人科学或魔法，而是普通的工程和物理定律。所有这些都运行在一个数据库服务器平台上；两对（生产和灾难恢复）服务器已退役并交给另一个部门。 5 个总计 720GB 的“数据库”被标准化为一个总计 450GB 的数据库。大约 700 个表（许多重复项和重复列）被规范化为 500 个不重复的表。它的执行速度要快得多，整体速度快了 10 倍，某些功能的速度快了 100 倍以上。这并不让我感到惊讶，因为那是我的意图，科学也预测到了这一点，但它让那些拥有咒语的人感到惊讶。

更多标准化

嗯，在每个项目中标准化都取得了成功，并且对所涉及的科学充满信心，标准化更多是一个自然的进展，而不是更少。以前3NF就足够了，后来NF还没有被识别出来。在过去 20 年里，我只交付了零更新异常的数据库，因此根据今天 NF 的定义，我一直交付 5NF。

同样，5NF 很棒，但也有其局限性。例如。旋转大型表（不是按照 MS PIVOT 扩展的小型结果集）的速度很慢。因此，我（和其他人）开发了一种提供标准化表格的方法，使得数据透视（a）简单并且（b）非常快。事实证明，既然 6NF 已经被定义，那么这些表就是 6NF。

由于我从同一个数据库提供 OLAP 和 OLTP，我发现，与科学一致，结构越标准化：

• 它们执行得越快

• 并且它们可以以更多方式使用（例如枢轴）

所以是的，我有一致且不变的经验，标准化不仅比非标准化或“德”快得多-标准化”； 更多标准化比更少标准化更快。

成功的标志之一是功能的增长（失败的标志是规模的增长但功能的增长）。这意味着他们立即要求我们提供更多的报告功能，这意味着我们标准化程度更高，并提供更多的专用表格（几年后证明是 6NF）。

围绕该主题取得进展。我一直是数据库专家，而不是数据仓库专家，因此我最初的几个仓库项目并不是成熟的实现，而是大量的性能调整任务。他们在我的范围内，在我专业的产品上。

我们不必担心标准化的确切水平等，因为我们正在研究典型的案例。我们可以认为，OLTP 数据库已合理标准化，但不具备 OLAP 能力，并且该组织购买了完全独立的 OLAP 平台、硬件；投资开发和维护大量 ETL 代码；等等。在实施之后，他们花了一半的时间来管理他们创建的重复项。在这里，书籍作者和供应商应该受到指责，因为他们导致组织购买了硬件和单独平台软件许可证的大量浪费。

• 如果您还没有观察到，我会请您注意典型的第一代“数据库”和典型的数据仓库之间的相似之处

同时，回到农场（上面的 5NF 数据库）我们只是不断添加越来越多的 OLAP 功能。当然，应用程序的功能有所增长，但这很小，业务没有改变。他们会要求更多的 6NF，而且很容易提供（5NF 到 6NF 是一小步；0NF 到任何东西，更不用说 5NF，都是一大步；有组织的架构很容易扩展）。

OLTP 和 OLAP 之间的一个主要区别（独立 OLAP 平台软件的基本理由）是 OLTP 是面向行的，它需要事务性安全的行并且速度快； OLAP 不关心事务问题，它需要列，而且速度快。这就是所有高端 BI 或 OLAP 平台都是面向列的原因，也是 OLAP 模型（星型模式、维度事实）是面向列的原因。

但对于 6NF 表：

• 没有行，只有列；我们以相同的令人眼花缭乱的速度提供行和列

• 表格（即6NF结构的5NF视图）已经组织成维度事实。事实上，它们被组织成比任何 OLAP 模型所能识别的更多维度，因为它们是所有维度。

• 通过动态聚合来透视整个表（与少量派生列的透视相反）是（a）毫不费力、简单的代码，并且（b）非常快
  

根据定义，我们多年来一直提供的是至少具有 5NF 的关系数据库供 OLTP 使用， 6NF 用于 OLAP 要求。

• 请注意，这与我们从一开始就使用的科学完全相同；从典型的非标准化“数据库”迁移到5NF企业数据库。我们只是应用更多经过验证的科学，并获得更高级别的功能和性能。

• 注意5NF企业数据库和6NF企业数据库之间的相似性

• 单独的 OLAP 硬件、平台软件、ETL、管理、维护的全部成本都被消除。

• 数据只有一个版本，无更新异常或维护；相同的数据为 OLTP 提供为行，为 OLAP 提供为列

我们唯一没有做的事情是开始一个新项目，并从一开始就声明纯 6NF。这就是我接下来要排队的。

什么是第六范式？

假设您了解规范化（我不会在这里不定义它），与此主题相关的非学术定义如下。请注意，它适用于表级别，因此您可以在同一数据库中混合使用 5NF 和 6NF 表：

• 第五范式：跨数据库解决所有功能依赖关系
  • 除了 4NF/BCNF
  • 每个非 PK 列与其 PK 都是 1::1
  • 没有其他PK
  • 无更新异常
    。
• 第六范式：是不可约NF，即数据不能进一步约简或归一化的点（不会有7NF）
  • 除了 5NF
  • 该行由一个主键和最多一个非键列组成
  • 消除了零问题

6NF 是什么样的？

数据模型属于客户，我们的知识产权不可免费出版。但我确实访问了这个网站，并提供了问题的具体答案。您确实需要一个真实的示例，因此我将发布我们内部实用程序之一的数据模型。

该数据用于收集任何时期任何客户的服务器监控数据（企业级数据库服务器和操作系统）。我们用它来远程分析性能问题，并验证我们所做的任何性能调整。该结构十多年来没有改变（添加，没有改变现有结构），这是典型的专业5NF，多年后被确定为6NF。允许完全旋转；在任何维度上绘制的任何图表或图形（提供 22 个枢轴，但这不是限制）；切片和切丁；混合搭配。请注意，它们是所有维度。

监控数据或指标或向量可以更改（服务器版本更改；我们想要获取更多内容），而不会影响模型（您可能还记得在另一篇文章中我说过 EAV 是 6NF 的私生子；这就是完整的 6NF，未稀释的父亲，因此提供了 EAV 的所有功能，而不牺牲任何标准、完整性或关系力）；您只需添加行。

▶监控统计数据模型◀。 （对于内联来说太大；某些浏览器无法加载内联；单击链接）

它允许我生成这些 ▶像这样的图表◀，收到客户的原始监控统计文件后按六次按键。注意混合搭配；操作系统和服务器在同一张图表上；各种枢轴。 （经许可使用。）

不熟悉关系数据库建模标准的读者可以找到 ▶IDEF1X 表示法◀ 有帮助。

6NF 数据仓库

最近已通过锚定建模验证了这一点，因为它们现在将 6NF 视为数据仓库的“下一代”OLAP 模型。 （他们不提供来自单一版本数据的 OLTP 和 OLAP，那是我们自己的）。

数据仓库（仅）经验

我仅在数据仓库（不是上述 6NF OLTP-OLAP 数据库）方面的经验是几项主要任务，而不是完整的实施项目。结果毫不奇怪：

• 与科学一致，标准化结构的执行速度要快得多；更容易维护；并且需要较少的数据同步。 Inmon，而不是 Kimball。

• 与魔法一致，在我对一堆表格进行归一化，并通过应用物理定律大幅提高性能后，唯一令人惊讶的是魔术师的咒语。

有科学头脑的人不会这样做；有科学头脑的人不会这样做。他们不相信也不依赖灵丹妙药和魔法；他们利用科学并努力工作来解决他们的问题。

有效的数据仓库理由

这就是为什么我在其他帖子中指出，单独的数据仓库平台、硬件、ETL、维护等的唯一有效理由是有许多数据库或“数据库”，全部合并到一个中央仓库中，用于报告和 OLAP。

Kimball

有必要谈谈 Kimball，因为他是数据仓库中“非规范化性能”的主要支持者。根据我上面的定义，他是那些显然在生活中从未正常化的人之一；他的起点是非标准化的（伪装为“非标准化”），他只是在维度事实模型中实现了这一点。

• 当然，为了获得任何性能，他必须更加“去规范化”，并创建更多的重复项，并证明这一切是合理的。

  • 因此，通过制作更专门的副本，以一种精神分裂的方式“去规范化”非规范化结构，“提高了读取性能”，这是事实。当考虑到整体时，情况就不是这样了。这只在那个小庇护所内是正确的，在外面则不然。

  • 同样，以这种疯狂的方式，所有“表”都是怪物的情况下，“连接是昂贵的”也是应该避免的。他们从未有过连接较小的桌子和集合的经验，因此他们无法相信更多、更小的桌子更快的科学事实。

  • 他们的经验是创建重复“表”的速度更快，因此他们无法相信消除重复的速度比这还要快。

    < /里>

• 他的维度添加到非标准化数据中。数据没有标准化，因此没有暴露任何维度。而在标准化模型中，维度已经公开，作为数据的组成部分，不需要添加。

• 金博尔那条铺得很好的路通向悬崖，在那里更多的旅鼠会更快地坠落死亡。旅鼠是群居动物，只要它们一起走，一起死，它们就死得很开心。旅鼠不会寻找其他路径。

所有这些都只是故事，是一个神话的一部分，相互关联、相互支持。

您的使命

如果您选择接受它。我要求你独立思考，停止任何与科学和物理定律相矛盾的想法。无论它们多么常见、神秘或神话。在相信任何事情之前先寻找证据。保持科学性，为自己验证新的信念。重复“为了性能而去规范化”的口头禅不会让你的数据库变得更快，它只会让你感觉更好。就像坐在场边的胖孩子告诉自己，他可以比比赛中的所有孩子跑得更快。

• 在此基础上，即使是“针对 OLTP 标准化”的概念却反其道而行之，“针对 OLAP 去标准化”也是一个矛盾。物理定律如何在一台计算机上按规定工作，但在另一台计算机上却相反？头脑令人难以置信。在每台计算机上都以同样的方式工作是根本不可能的。

问题 ？

Answer 2

非规范化和聚合是用于实现数据仓库性能的两种主要策略。认为它不能提高读取性能是愚蠢的！我肯定在这里误解了什么？

聚合：
考虑一个包含 10 亿次购买的表。
将其与一张表格进行对比，该表格中的一行包含购买的总和。
现在，哪个更快？从 10 亿行表中选择 sum(amount) 还是从 1 行表中选择 amount？这当然是一个愚蠢的例子，但它非常清楚地说明了聚合的原理。为什么更快？因为无论我们使用什么神奇的模型/硬件/软件/宗教，读取 100 字节都比读取 100 GB 快。就这么简单。

非规范化：
零售数据仓库中的典型产品维度包含大量列。有些列很简单，例如“名称”或“颜色”，但也有一些复杂的内容，例如层次结构。多个层次结构（产品范围（5 个级别）、目标买家（3 个级别）、原材料（8 个级别）、生产方式（8 个级别）以及一些计算数字，例如平均交货时间（自年初以来）我维护了一个包含 200 多个列的产品尺寸表，该表是由来自 5 个不同源系统的约 70 个表构建的，争论是否对标准化模型进行查询（如下）是很愚蠢的。

select product_id
  from table1
  join table2 on(keys)
  join (select average(..)
          from one_billion_row_table 
         where lastyear = ...) on(keys)
  join ...table70
 where function_with_fuzzy_matching(table1.cola, table37.colb) > 0.7
   and exists(select ... from )
   and not exists(select ...)
   and table20.version_id = (select max(v_id from product_ver where ...)
   and average_price between 10 and 20
   and product_range = 'High-Profile'

...比非规范化模型上的等效查询更快：

select product_id
  from product_denormalized
 where average_price between 10 and 20
   and product_range = 'High-Profile';

为什么？部分原因与聚合场景相同，但也因为查询太复杂了（现在我'）。如果查询处理少量数据，那么执行计划可能会变得混乱并搞砸。但是一旦我们开始加入大表，情况就会变得。 >数据库正确执行执行计划至关重要。使用单个合成键对一个表中的数据进行非规范化（哎呀，为什么我不为这场持续的大火添加更多燃料），过滤器成为预煮列上的简单范围/相等过滤器。将数据复制到新列中使我们能够收集有关列的统计信息，这将有助于优化器估计选择性，从而为我们提供正确的执行计划（嗯，...）。

显然，使用非规范化和聚合会使适应模式更改变得更加困难，这是一件坏事。另一方面，它们提供了读取性能，这是一件好事。

那么，您是否应该对数据库进行非规范化以实现读取性能？
天哪，不！它给你的系统增加了如此多的复杂性，以至于在你交付之前它会以无数种方式把你搞砸。值得吗？是的，有时您需要这样做才能满足特定的性能要求。

更新 1

PerformanceDBA：1 行每天更新十亿次

这意味着（接近）实时要求（这反过来又会产生一组完全不同的技术要求）。许多（如果不是大多数）数据仓库没有这种要求。我选择了一个不切实际的聚合示例，只是为了阐明聚合为何有效。我也不想解释汇总策略 :)

另外，必须将数据仓库的典型用户和底层 OLTP 系统的典型用户的需求进行对比。如果用户想要了解哪些因素会影响运输成本，那么他们不会关心当今 50% 的数据是否丢失，或者是否有 10 辆卡车爆炸并导致司机死亡。即使他拥有最新的信息，对两年的数据进行分析仍然会得出相同的结论。

将此与卡车司机（幸存的司机）的需求进行对比。他们不能仅仅因为一些愚蠢的聚合过程必须完成而在某个中转站等待 5 个小时。拥有两个独立的数据副本可以满足这两个需求。

为操作系统和报告系统共享同一组数据的另一个主要障碍是发布周期、问答、部署、SLA 等等都非常不同。同样，拥有两个单独的副本使这更容易处理。

Answer 3

我将“OLAP”理解为用于决策支持的面向主题的关系/SQL 数据库 - 又称数据仓库。

范式（通常是第五/第六范式）通常是数据仓库的最佳模型。规范化数据仓库的原因与任何其他数据库完全相同：减少冗余并避免潜在的更新异常；它避免了内置偏差，因此是支持模式更改和新需求的最简单方法。在数据仓库中使用范式还有助于保持数据加载过程简单且一致。

不存在“传统的”非规范化方法。好的数据仓库总是标准化的。

Answer 4

数据库不应该为了读取性能而进行非规范化吗？

好吧，这里是“你的里程可能会有所不同”，“这取决于”，“为每项工作使用适当的工具”，“一种尺寸并不适合所有”的答案，还有一点“如果它不修复它” Ain't Broken”抛出：

非规范化是在某些情况下提高查询性能的一种方法。在其他情况下，它实际上可能会降低性能（因为磁盘使用量增加）。这无疑使更新变得更加困难。

仅当遇到性能问题时才应考虑它（因为您提供了标准化的好处并引入了复杂性）。

非规范化的缺点是对于从未更新或仅在批处理作业中更新的数据（即不是 OLTP 数据）而言问题不大。

如果非规范化解决了您需要解决的性能问题，而侵入性较小的技术（如索引或缓存或购买更大的服务器）无法解决，那么是的，您应该这样做。

Answer 5

首先是我的观点，然后是一些分析

观点
非规范化被认为有助于读取数据，因为非规范化一词的常见用法通常不仅包括破坏正常形式，还包括向系统引入任何插入、更新和删除依赖项。

严格来说，这是错误，请参阅此问题/答案 ，严格意义上的非规范化意味着打破 1NF-6NF 中的任何范式，其他插入、更新和删除依赖关系通过 正交设计原理。

因此，人们采用空间与时间权衡原则并记住术语冗余（与非规范化相关，但仍然不等于它）并得出结论，你应该有好处。这是错误的暗示，但错误的暗示不允许你得出相反的结论。

打破范式可能确实会加快某些数据检索速度（详细信息见下文分析），但通常它也会同时：

• 只支持特定类型的查询，并且减慢所有其他访问路径
• 增加系统的复杂性（这不仅影响数据库本身的维护，而且还增加使用数据的应用程序的复杂性）
• 混淆和削弱数据库的语义清晰度
• 数据库系统的要点，作为中心代表问题空间的数据要公正地记录事实，这样当需求发生变化时，您不必重新设计系统中实际上独立的部分（数据和应用程序）。为了能够做到这一点，人为的依赖关系应该最小化——今天加速一个查询的“关键”要求常常变得微不足道。

分析

因此，我声称​​有时打破正常形式可以帮助检索。是时候给出一些论据了

1) 打破 1NF

假设您有 6NF 的财务记录。从这样的数据库中，您肯定可以获得有关每个帐户每月余额的报告。

假设必须计算此类报告的查询需要遍历 n 条记录，您可以创建一个表

account_balances(month, report)

来保存每个帐户的 XML 结构化余额。这会破坏 1NF（请参阅后面的注释），但允许使用最小 I/O 执行一个特定查询。

同时，假设可以通过插入、更新或删除财务记录来更新任何月份，则系统上更新查询的性能可能会因与 n 对于每次更新。
（上面的例子说明了一个原则，实际上你会有更好的选择，并且获得最小 I/O 的好处会带来这样的惩罚，对于经常更新数据的现实系统，即使是你的目标查询，也会得到糟糕的性能，具体取决于实际工作负载的类型；如果需要，可以更详细地解释这一点）

注意：
这实际上是一个微不足道的例子，但它有一个问题——1NF 的定义。上述模型违反 1NF 的假设是根据属性值“仅包含适用域中的一个值”的要求。

这允许您说属性报告的域是所有可能报告的集合，并且所有报告中都只有一个值，并声称 1NF 没有被破坏（类似于存储单词不会破坏 1NF 的论点，即使您的模型中的某处可能有letters 关系）。

另一方面，有更好的方法来对该表进行建模，这对于更广泛的查询更有用（例如检索一年中所有月份的单个帐户的余额）。在这种情况下，您可以通过说该字段不在 1NF 中来证明该改进的合理性。

无论如何，它解释了为什么人们声称打破 NF 可能会提高性能。

2) 打破 3NF

假设 3NF 中的表

CREATE TABLE `t` (
  `id` int(10) unsigned NOT NULL AUTO_INCREMENT,
  `member_id` int(10) unsigned NOT NULL,
  `status` tinyint(3) unsigned NOT NULL,
  `amount` decimal(10,2) NOT NULL,
  `opening` decimal(10,2) DEFAULT NULL,
  PRIMARY KEY (`id`),
  KEY `member_id` (`member_id`),
  CONSTRAINT `t_ibfk_1` FOREIGN KEY (`member_id`) REFERENCES `m` (`id`) ON DELETE CASCADE ON UPDATE CASCADE
) ENGINE=InnoDB

CREATE TABLE `m` (
  `id` int(10) unsigned NOT NULL AUTO_INCREMENT,
  `name` varchar(255) DEFAULT NULL,
  PRIMARY KEY (`id`)
) ENGINE=InnoDB

包含示例数据（t 中有 1M 行，m 中有 100k）

假设您想要改进一个常见查询，

mysql> select sql_no_cache m.name, count(*) 
       from t join m on t.member_id = m.id 
       where t.id between 100000 and 500000 group by m.name;
+-------+----------+
| name  | count(*) |
+-------+----------+
| omega |       11 |
| test  |        8 |
| test3 |   399982 |
+-------+----------+
3 rows in set (1.08 sec)

您可以找到移动属性 name name 且 member_id 不是 t 的键）

code> 到表 m 中，在

alter table t add column varchar(255);
update t inner join m on t.member_id = t.id set t.name = m.name;

运行

mysql> select sql_no_cache name, count(*) 
       from t where id 
       between 100000 and 500000 
       group by name;
+-------+----------+
| name  | count(*) |
+-------+----------+
| omega |       11 |
| test  |        8 |
| test3 |   399982 |
+-------+----------+
3 rows in set (0.41 sec)

注释 ：
上面的查询执行时间减少了一半，但是

• 该表一开始就不在 5NF/6NF 中，
• 测试是使用 no_sql_cache 完成的，因此避免了大多数缓存机制（并且在实际情况下它们发挥了作用）在系统性能方面）
• 空间消耗增加了大约 9x 列名称大小 x 100k 行
• t 上应该有触发器以保持数据的完整性，这将显着减慢对 name 的所有更新，并添加在 t 中插入的额外检查需要经历
• 可能更好的结果可以通过删除代理键并切换到自然键和/或索引，或重新设计到更高的 NF 来实现

从长远来看，规范化是正确的方法。但您并不总是可以选择重新设计公司的 ERP（例如，大多数情况下已经只有 3NF） - 有时您必须在给定资源内完成某些任务。当然，这样做只是短期的“解决方案”。

底线

我认为对你的问题最相关的答案是，你会发现行业和教育在

• 严格意义上使用“非规范化”一词，以松散地打破NF
• ，用于引入任何插入、更新和删除依赖项（Codd 的原始引用评论关于规范化的说法：“不受欢迎的（！）插入、更新和删除依赖项'，请参阅此处）

因此，在严格的定义下，聚合（汇总表）是不被视为非规范化，它们在性能方面可以提供很大帮助（任何缓存也一样，这不被视为非规范化）。

宽松的用法涵盖了破坏范式和正交设计原则，如前所述。

另一件可能说明的事情是，逻辑模型和物理模型之间存在非常重要的区别。

例如，索引存储冗余数据，但没有人认为它们是非规范化，即使是宽松地使用该术语的人也不会认为它们是非规范化，这有两个（相关的）原因：

• 它们不是逻辑模型的一部分
• ，它们是透明的，并保证不会破坏逻辑模型的完整性。你的模型

如果你不能正确地对你的逻辑模型进行建模，你最终会得到不一致的数据库——实体之间的关系类型错误（无法表示问题空间）、相互冲突的事实（丢失信息的能力），你应该使用任何你能使用的方法为了获得正确的逻辑模型，它是构建在其之上的所有应用程序的基础。

谓词的规范化、正交和清晰的语义、定义良好的属性、正确识别的函数依赖关系都是避免陷阱的因素。

当涉及到物理实现时，事情会变得更加轻松，从某种意义上说，依赖于非键的物化计算列可能会破坏 3NF，但如果存在保证一致性的机制，则在物理模型中允许它以与索引相同的方式是允许的，但你必须非常仔细证明它的合理性，因为通常规范化会产生相同或更好的全面改进，并且不会产生或更少的负面影响，并且会保持设计清晰（这减少了应用程序开发的时间）和维护成本），从而节省成本，您可以轻松地用于升级硬件，以提高速度，甚至比破坏 NF 所实现的速度还要快。

Answer 6

构建数据仓库 (DW) 的两种最流行的方法似乎是 Bill Inmon 和 Ralph Kimball 的方法。

Inmon 的方法使用标准化方法，而 Kimball 的方法使用维度建模——非标准化星型模式。

两者都有详细的记录，甚至都有很多成功的实施。两者都为 DW 目的地提供了一条“宽阔、铺好的道路”。

我无法评论 6NF 方法或锚定建模，因为我从未见过或参与过使用该方法的 DW 项目。当谈到实现时，我喜欢沿着经过良好测试的路径前进——但是，这只是我自己的想法。

那么，总结一下，DW 应该标准化还是非标准化？取决于您选择的方法 - 只需选择一种方法并坚持下去，至少直到项目结束。

编辑 - 示例

在我目前工作的地方，我们有一个遗留报告，该报告一直在生产服务器上运行。这不是一份简单的报告，而是每天通过电子邮件发送给每个人和他的蚂蚁的 30 个子报告的集合。

最近，我们实现了一个DW。有了两个报表服务器和一堆报表，我希望我们可以忘记遗留的事情。但不是，遗产就是遗产，我们一直拥有它，所以我们想要它，需要它，没有它就活不下去，等等。

问题是，Python 脚本和 SQL 的混乱花了八个小时（是的，八个小时）小时）每天运行。不用说，数据库和应用程序是由几批开发人员多年来构建的 - 因此，不完全是您的 5NF。

是时候重新创建 DW 遗留下来的东西了。好的，为了简短起见，它已经完成了，需要 3 分钟（三分钟）来生成它，每个子报告需要 6 秒。而且我急于交付，所以甚至没有优化所有查询。速度提高了 8 * 60 / 3 = 160 倍——更不用说从生产服务器中删除 8 小时作业的好处了。我想我还能节省一分钟左右的时间，但现在没人在乎。

有趣的是，我在 DW 中使用了 Kimball 的方法（维度建模），并且这个故事中使用的所有内容都是开源的。

我认为这就是所有这些（数据仓库）的意义所在。使用哪种方法（标准化或非标准化）是否重要？

编辑2

作为一个兴趣点，Bill Inmon 在他的网站上有一篇写得很好的论文 - 两种架构的故事。

Answer 7

“非规范化”这个词的问题在于它没有指定前进的方向。这就像试图从纽约开车从芝加哥到达旧金山一样。

星型模式或雪花型模式当然没有标准化。在某些使用模式下，它的性能肯定比规范化模式更好。但在某些非规范化的情况下，设计者根本不遵循任何规则，而只是凭直觉构建表格。有时这些努力不会成功。

简而言之，不要只是非规范化。如果您对不同的设计准则的好处充满信心，即使它不符合规范化设计，也请遵循不同的设计准则。但不要用非规范化作为随意设计的借口。

Answer 8

简短的回答是不要解决尚未解决的性能问题！

对于基于时间的表，普遍接受的范式是每行都有 valid_from 和 valid_to 日期。这基本上仍然是 3NF，因为它只是将语义从“这是该实体的唯一版本”更改为“这是该实体目前唯一的版本”

Answer 9

简化：

OLTP 数据库应该标准化（只要有意义）。

OLAP 数据仓库应非规范化为事实表和维度表（以最小化连接）。