SQL 向左，DAX 向右：数据库范式与分析范式的思维碰撞

本文对比 SQL LEFT JOIN 与 DAX 的思维差异，通过具体示例阐明数据库范式与分析范式下的关联逻辑与应用场景。

喜乐君注：在学习 Tableau 的路上，我日渐兼修了PowerBI 和 DAX 知识，虽然不算娴熟，但基本了解了它们的技术逻辑。也写过几篇“Power 向左、Tableau 向右”主题的问题，颇为欢迎。

如今，我想对比一下 SQL 和 DAX 的差异。

引言：数据世界的两种“母语”

在浩瀚的数据世界里，SQL (Structured Query Language) 以其超过半个世纪的统治力，成为了无可争议的“世界语”。任何与数据打交道的人，都无法绕开它。然而，随着商业分析的复杂度与实时性要求日益提高，人们逐渐发现，这门“世界语”在某些场景下显得愈发“笨拙”和冗长。

正是在这样的背景下，一门全新的语言——DAX (Data Analysis Expressions) 应运而生。它并非SQL的替代品，而是一种从根本上为“分析”而生的新范式。它代表了一种与SQL截然不同的思考数据的方式。

概述：工具对比的本质——两种范式的对决

本文将沿用“向左，向右”的分析框架，深入剖析 SQL 所代表的“数据库范式”与 DAX 所代表的“分析范式”在哲学思想、设计逻辑和应用场景上的本质区别。在深入它们的分歧之前，我们有必要先看看这两位“巨人”共同站立的基石，再追溯其分道扬镳的历史根源，最后通过七个维度的直接对话，彻底理解它们的本质不同。

第一部分：求同存异 —— SQL 与 DAX 的共同基石

尽管我们强调其差异，但 SQL 与 DAX 并非全然对立。它们共享着作为现代数据语言的某些根本属性，这些共性是它们能够成为各自领域基石的原因。

1.1 数据交互的本质： 它们都是为“与数据对话”而生的领域专用语言（DSL），是人类与结构化数据存储之间沟通的桥梁，核心使命都是从数据中提取信息。

1.2 声明式的优雅： 两者都是声明式语言。使用者只需“声明”想要什么（What），而无需关心底层引擎如何（How）去实现。这使得它们在数据处理上更简洁、门槛更低，让使用者能更专注于业务逻辑本身。

1.3 大数据分析的能力： 两者都能处理海量数据。SQL 依托于强大的分布式数据库引擎（如 Spark SQL, Presto），DAX 则依赖于其背后高效的 VertiPaq 列式内存引擎。在各自的体系内，它们都具备处理亿级甚至更大规模数据的计算能力。

1.4 嵌入与集成的开放性： 两者都具备良好的生态集成性。SQL 可以被嵌入到几乎所有的编程语言和应用程序中；DAX 则作为微软分析平台的核心，能与 Power BI、Excel、SQL Server Analysis Services 等无缝集成。

第二部分：分道扬镳 —— 历史、使命与受众的差异

正是因为历史背景、核心使命和目标用户的不同，决定了 SQL 和 DAX 从诞生之初就走向了两条截然不同的道路。

2.1 历史渊源：生于“数据库时代” vs. 生于“分析时代”

2.2 核心使命：管理“数据资产” vs. 创造“业务洞察”

2.3 目标用户：数据工程师 vs. 数据分析师

第三部分：范式对决 —— 七个维度的深度比较（文章核心）

这部分是文章的核心。我们将通过七个关键维度的直接对比，深入剖析两种范式的本质不同。

SQL 向左，DAX 向右：数据库范式与分析范式的思维碰撞

导言：数据交互的两种范式

在数据科学与商业智能领域，结构化查询语言（SQL）与数据分析表达式（DAX）是两座无法绕开的高峰。然而，它们并非简单的同类竞争者，而是代表了两种截然不同的数据交互世界观。SQL 是数据状态管理的语言，其核心关注点在于信息的持久化、结构化完整性与一致性。DAX 则是分析建模的语言，其设计初衷是为了实现动态的、上下文敏感的复杂计算。本文标题中的“向左”与“向右”正象征着这一根本性的分野：SQL 承载着构建数据基石的结构化、基础性工作（左），而 DAX 则释放了基于数据进行探索、创造与分析的灵活性（右）。

这两种语言的基因差异，是其诞生时代所面临核心问题的直接产物。SQL 的起源可追溯至 20 世纪 70 年代，旨在解决大型共享数据银行中数据存取的复杂性问题 。当时，数据库专家需要一种能从复杂的层级或网状数据库中解放出来的工具，以提高编程效率和数据独立性。埃德加·科德（Edgar F. Codd）的关系模型及其催生的 SQL，正是为数据库专家管理中央共享资源而设计的解决方案 。数十年后，微软的“双子座计划”（Project Gemini）则旨在解决一个截然不同的商业痛点：业务分析师对 IT 部门的高度依赖，以及由此带来的分析敏捷性缺失 。其解决方案 DAX，是一种为 Excel 用户量身定制的公式语言，它在内存模型之上运行，核心目标是赋予业务人员探索数据的能力。因此，SQL 的设计解决了程序员的效率问题，而 DAX 的设计则解决了分析师的敏捷性问题。这种根本性的目标差异，决定了它们后续在哲学、架构和语法上的巨大分野。

为了在深入探讨前建立一个宏观框架，下表对两种范式的核心维度进行了高阶对比，它将作为贯穿全文的参照系。

核心之辩：状态 vs. 上下文

如果说引擎架构是 SQL 和 DAX 的“身体”，那么它们处理数据的核心逻辑——状态（State）与上下文（Context）——就是它们的“灵魂”。SQL 的世界观是绝对的、基于静态集合的；而 DAX 的世界观则是相对的、基于动态上下文的。理解这一根本差异，是跨越两种范式思维鸿沟的关键。

4.1 SQL 的世界观：操作静态集合

一个 SQL 查询的执行过程，本质上是对数据库在某个时间点上的静态快照进行的一系列集合运算。其逻辑流程清晰而确定：

在整个查询执行期间，被操作的数据集合是固定的。对于一个给定的数据库状态，无论何时执行相同的 SQL 查询，其返回的结果集都是完全相同、绝对不变的。这个结果集本身也是一个静态的、新的表。SQL 的思维模式是线性的、程序化的，它通过一系列明确的步骤，从一个已知的、静态的数据状态中，精确地提取出一个新的、同样静态的数据子集。

4.2 DAX 的世界观：评估上下文

与 SQL 的绝对主义截然不同，DAX 的计算是在一个动态的、多层次的“评估上下文”（Evaluation Context）中进行的。任何一个 DAX 表达式的值都不是孤立存在的，它的结果完全取决于其被评估时所处的环境。这个评估上下文是 DAX 最核心、也最难掌握的概念，它由两个主要部分组成：行上下文（Row Context）和筛选上下文（Filter Context）。

4.3 CALCULATE：动态分析的引擎

如果说评估上下文是 DAX 的灵魂，那么 CALCULATE 函数就是驱动这个灵魂的心脏。它是 DAX 中功能最强大、也是最重要的函数。其基本语法是 CALCULATE(<expression>, <filter1>, <filter2>,...)，其核心作用是在一个修改过的筛选上下文中评估指定的表达式 。

CALCULATE 的魔力在于其“上下文转换”（Context Transition）的能力 。当 CALCULATE 函数在一个已经存在行上下文的环境中被调用时（例如，在计算列或迭代器函数内部），它会执行一个神奇的操作：将当前的行上下文“提升”为一个新的筛选上下文 。这个新生成的筛选上下文会过滤整个数据模型，使其只包含当前行所代表的数据。

例如，在 Product 表中创建一个计算列 CALCULATE(SUM(Sales[Quantity]))：

这个“上下文转换”机制是 DAX 独有的，它在行级迭代和模型级筛选之间架起了一座桥梁，使得在逐行计算的过程中，可以引用和操作整个数据模型经过筛选后的聚合结果。这是 SQL 中没有直接对应物的强大概念。

4.4 实践体现：计算列 vs. 度量值

计算列和度量值（Measures）的区别，是理解行上下文与筛选上下文在实践中如何运作的最佳范例 。

一个计算列 [Price] * [Quantity] 是在行上下文中工作的，它在每一行独立计算，结果是静态的，存储下来。而一个度量值 SUMX(Sales, Sales[Price] * Sales[Quantity]) 则是在筛选上下文中工作的，它的结果是动态的，取决于用户在报表中的交互。

最终，我们可以得出这样一个结论：SQL 查询的结果是绝对的，它反映了数据库在某个时刻的真实状态。而 DAX 度量值的结果是相对的，它是一个公式，其值取决于观察它的“参考系”——即评估上下文。CALCULATE 赋予了分析师操纵这个参考系的能力，从而实现了 SQL 难以企及的动态分析深度和灵活性。这正是从数据库范式到分析范式的核心思维跃迁。

SQL 向左，DAX 向右：范式的综合

在深入剖析了 SQL 与 DAX 的起源、架构和核心理念之后，我们不应将它们视为相互竞争、非此即彼的技术，而应理解为在现代数据工作流中相辅相成、各司其职的两种范式。它们之间的“碰撞”并非一场零和博弈，而是在现代数据栈中形成的一种高效分工与协作。

5.1 现代数据栈：一种共生关系

现代数据生态系统清晰地划分了数据处理的不同阶段，而 SQL 和 DAX 正好完美地契合了其中的关键环节，并分别对应着数据团队中的核心角色：数据工程师（Data Engineer）和数据分析师/商业智能开发者（Data Analyst / BI Developer）。

5.2 两种思维模式的交响

掌握 SQL 和 DAX 不仅仅是学习两种语法，更是培养两种截然不同的思维模式。

现代数据栈的成功，正是源于对这两种范式和思维模式的深刻理解与制度化。它通过明确的角色分工（数据工程师 vs. 数据分析师）和技术栈分离（数据仓库 vs. BI 工具），为 SQL 和 DAX 的协同工作创造了理想的环境。数据工程师使用 SQL “向左”，为分析构建坚实的地基；数据分析师使用 DAX “向右”，在地基之上建造洞察的高楼。这种看似“碰撞”的范式差异，最终在实践中谱写出了一曲高效协作的数据价值交响乐。

附录：DAX 基础文献的比较分析

A.1 引言：两种思想流派

DAX 语言的底层机制是确定且唯一的，但通往精通之路的教学方法与认知框架却可以有不同的流派。在 DAX 学习社区中，两部著作分别代表了两种极具价值但视角不同的思想体系。通过对它们的比较分析，我们可以更深刻地理解掌握 DAX 所需的知识二元性：既要懂其然，也要懂其所以然。

A.2 经典范式：《DAX 权威指南》by Russo and Ferrari

由 Marco Russo 和 Alberto Ferrari 合著的《The Definitive Guide to DAX》被全球 DAX 社区公认为“圣经” 。这本书的教学方法是严谨的、自下而上的，它从 DAX 引擎的内部工作原理出发，来解释语言的每一个行为。

其核心贡献在于对 DAX 引擎三大基石的权威阐释：

《DAX 权威指南》的アプローチ是工程师式的。它通过揭示“它如何工作”（how it works）的底层逻辑，赋予读者解决复杂问题和进行深度性能优化的能力。对于任何希望成为 DAX 专家的从业者而言，这本书是不可或缺的技术基石。

A.3 另辟蹊径：《DAX 别裁新解》by 喜乐君

喜乐君的著作（根据用户查询所提供的框架推断）则代表了另一种教学思想。它似乎更侧重于从分析师的业务视角出发，构建一个自上而下的、更符合人类认知习惯的 conceptual framework，来帮助读者理解和应用 DAX。

其独特的贡献可能体现在以下几个方面：

《DAX 别裁新解》的アプローチ是分析师式的。它通过提供一个“如何思考它”（how to think about it）的认知框架，帮助读者建立正确的 DAX 思维模式，使写出的代码不仅技术上正确，而且逻辑上优雅，与业务问题高度契合。