演示 ANSI SQL 习语，通过不使用专有的 UNPIVOT 操作符或 LATERAL 派生表将多个属性列解转为规范的键值行？

问题的回答。

问题的历史。

此需求源自于从传统电子表格系统或平面文件导出的数据摄取管道，其中时间序列指标或类别属性被解规范化为宽格式列标题（例如，Jan_Sales，Feb_Sales），而不是规范化的行。这种模式在 Excel 驱动的商业过程中在 ETL 进入关系数据仓库之前很常见，要求转换为狭窄的事实表以启用时间分析和维度 JOIN。挑战在于将这些静态列投影转化为动态元组流，而不依赖于逐行处理的命令式方法。

问题。

标准 SELECT 语句在解析时固定了投影列的身份，阻止单个投影在不同的输出行上发出不同的源列，而没有 LATERAL 相关或过程迭代。目标是制造每个源行与枚举属性名称的虚拟维度表之间的笛卡尔积，然后通过条件逻辑将正确的源值多路复用到通用结果列中。这必须仅使用 ANSI SQL:1999 及更高版本中可用的标准连接语法和标量表达式来完成。

解决方案。

利用 CROSS JOIN 结合通过 VALUES 行构造器表达的派生表，该构造器将类别键（例如月份名称）枚举为行。在 SELECT 列表中，使用searched CASE 表达式将每个键映射到其对应的源列，有效地将解规范化的值投射到规范化的行结构中。过滤结果以排除当特定键缺少源属性时生成的 NULL 值，确保最终输出仅包含有效度量。

SELECT 
  s.cost_center_id,
  m.fiscal_month,
  CASE m.fiscal_month
    WHEN 'M01' THEN s.m01_amt
    WHEN 'M02' THEN s.m02_amt
    WHEN 'M03' THEN s.m03_amt
    -- ... 额外月份
    WHEN 'M12' THEN s.m12_amt
  END AS amount
FROM budget_wide s
CROSS JOIN (
  VALUES ('M01'), ('M02'), ('M03'), ('M04'), 
         ('M05'), ('M06'), ('M07'), ('M08'), 
         ('M09'), ('M10'), ('M11'), ('M12')
) AS m(fiscal_month)
WHERE CASE m.fiscal_month 
        WHEN 'M01' THEN s.m01_amt 
        -- ... 为避免 NULLs 重复所有
      END IS NOT NULL;

生活中的情况

一个财务部门从企业 Excel 模型导出了财政年度预算分配到一个临时表中，其中十二个月列（M01_Amt 到 M12_Amt）表示每个成本中心的解规范化时间段。目标 SAP 数据仓库需要一个狭窄的事实表模式（CostCenter_ID，Fiscal_Month，Amount），需要在 ANSI SQL 加载脚本中进行未转置转换，以避免中间 Python 处理。五千万条记录的数量排除了手动转换或多次加载策略。

解决方案 1：每列的联合所有。

最初的方法使用了十二个单独的 SELECT 查询，每个查询投影出不同的月份列硬编码到通用的 Amount 和 Month_Name 列中，并通过 UNION ALL 组合起来。优点：该方法享有普遍兼容性，可以在缺乏现代连接语法的传统主机数据库和过时的 SQL 引擎上运行。缺点：对源数据执行了十二次完整表扫描，导致线性 I/O 降级；查询计划变得庞大且难以缓存，而任何模式修改（添加第十三个期间）都需要更改十二个单独的投影列表。

解决方案 2：动态 SQL 生成。

另一种方法涉及在应用层动态构建查询文本，通过迭代元数据表在运行时生成所需的 CASE 分支或 UNION 分支。优点：这为不断发展的模式提供了灵活性，并减少了处理数百列时手动编写 SQL 的麻烦。缺点：它违反了对过程逻辑的禁止；它引入了 SQL 注入攻击向量和编译开销，并且生成的语句无法封装在静态数据库视图或存储过程定义中。

解决方案 3：带有值的交叉连接。

接受的实现采用了带有 VALUES 构造器定义的 CROSS JOIN，多路复用正确的金额通过以虚拟期标识符为关键的 CASE 表达式。优点：它对源表执行为单次扫描，利用高效的连接算法，并且在 Oracle、SQL Server、PostgreSQL 和 Db2 中完全声明式和可移植，且不需要供应商提示。缺点：它要求 SQL:1999 支持行构造器，而过时的系统上不可用，并且 CASE 表达式的冗长增加了维护开销，除非通过模板生成。

结果。

通过消除 UNION ALL 模式中固有的冗余表扫描，转换延迟从二十五分钟减少到不足九十秒。加载过程对于模式扩展变得弹性，仅在引入新财政期间时需要在 VALUES 构造器中添加一行。此外，逻辑被封装在标准视图中，使得 Tableau 用户能够直接进行临时查询，而无需中间 ETL 步骤。

候选人通常遗漏的内容

如何防止源列中的 NULL 值出现在解转置结果中而不导致 CASE 表达式在执行计划中被评估两次？

候选人经常在 WHERE 子句谓词中嵌入 CASE 表达式，如 WHERE CASE ... END IS NOT NULL，这迫使优化器计算投影两次 - 一次用于过滤，一次用于输出。有效的 ANSI SQL 模式将结果实体化在派生表或 公共表表达式 (CTE) 中：SELECT * FROM (SELECT ..., CASE ... END AS val FROM ... CROSS JOIN ...) sub WHERE val IS NOT NULL。这只计算一次 CASE，过滤出行，保持查询优化器的关注点清晰分离。

当解转置具有异构数据类型的列（例如，带有 DECIMAL 金额列的 VARCHAR 评论列）时，什么特定的 ANSI SQL 类型转换策略确保在单个结果值列中没有数据损失的类型一致性？

许多候选人错误地依赖隐式类型转换，这可能会截断字符串或丢失小数精度，或者他们尝试 UNION ALL 而没有意识到不同平台的类型强制规则。稳健的解决方案在每个 WHEN 分支的 CASE 表达式中显式地将每个源列转换为一个共同的超类型 - 通常为 VARCHAR ：CASE WHEN key='Comment' THEN CAST(text_col AS VARCHAR(500)) ELSE CAST(num_col AS VARCHAR(500)) END。这确保了所有返回值共享一个与结果列定义兼容的单一数据类型，在必要时保留数值数据的文本表示。

为什么带有 VALUES 的 CROSS JOIN 方法表面上似乎会导致笛卡尔积爆炸，优化器通常如何缓解与本地 UNPIVOT 操作符的 NULL 消除行为相比？

CROSS JOIN 在逻辑上生成 M×N 行（源行乘以属性计数），在过滤之前，候选人担心这会在大数据集上降低性能。然而，现代基于成本的优化器识别 CASE 表达式对小常量表的数据依赖，并通常将计划转换为简单投影或内部的 UNPIVOT 物理操作，从而避免实际的行乘法。与本地 UNPIVOT 不同，后者通常会自动消除 NULL 结果，这种方法需要显式的 WHERE 子句来丢弃源属性为 NULL 的行，否则结果集将包含伪空事实，从而破坏下游的聚合计算。