第十四章读者视角自审：QM 内关联多个 TM

2026-10-21。按用户纠正重做，上一轮把“QM 内 JOIN 两个 TM”误解为“动态组合多个 QM”，旧稿与旧自审已明确移往高级素材。

主线和精简

• 开篇回顾 TM 的事实/维度和雪花映射，再以订单/支付、账单/明细说明多事实关联常见；不声称 TM 不能处理关联。
• 当前章只讲建模：一个 QM 的主 model、joins、columnGroups；再定义 groupBy/sum/count/as 聚合 relation。查询端只有一个 QM 加普通 DSL，不出现 Compose 脚本。
• 两组任务都把创建与查询分开，提示词短，期间沿用已确认的 2012 年。两个源 TM 复用，仅两个新 QM，各完整源码只出现一次。
• 用同一账单/明细 TM 对比 447 行和 83 行；4256.25 与 477.53 是粒度变化的实际结果，不归因于引擎金额算错。
• 明确 QM 内 relation 的 groupBy 在 JOIN 前，查询 DSL 的 groupBy 在其后，避免读者以为外层分组可以消除金额重复。
• 先解释每张账单对账，再简述同一 QM 按客户汇总，无须再贴一套相似 DSL。销售/支付仅作动机，不虚构 Chinook 支付数据。

验证和边界

10 项普通 QM 查询独立核对完成；错误字段在 query.validate 拒绝，聚合 relation 的 INNER 在 models.validate 明确拒绝。两类拒绝均未执行。临时 QM 测试右侧无匹配保留左侧，数据未改，字段省略不说成零。

当前聚合 relation 仅 LEFT JOIN 的边界已写清；普通 INNER 在样例完整关联时为 447 行，不能拿它冒充无匹配差异测试。三个旧查询回归通过，临时测试 Bundle 已清理，原八个模型与数据库摘要不变；只保留两个新正式 QM。

模型 Markdown 明确由已加载代码自动生成、实时读取。源码块和 JSON 与实际文件逐项对照；链接、围栏、标题、前后章过渡与当前大纲同步。

未将旧 Compose 验收数套到新章，未把 #150/#151 写成当前建模路径的限制。没有重新提交或关闭 GitHub issue，没有另开干净 Codex 会话独立测试。

当前稿交用户审阅，后章未开始。新实操记录。

补充主 TM 与结果粒度的说明

在普通 JOIN 的行数、金额示例之后，聚合 JOIN 之前，补充两种查询目标：账单为主查账单指标时，通常聚合明细后关联；明细为主取账单属性时，可用 TM 维度或 QM 多对一 JOIN。强调主 TM 是查询起点，不保证关联后仍保持原粒度；直接展开明细合理，但账单总额不能当明细可加指标。仅补说明，不改模型和查询，沿用已有证据，不重跑。

整体精简复审

将主 TM 选择表前移到创建步骤之前，先说明查询目标与结果粒度；随后按普通 JOIN 展开、金额重复、聚合 JOIN 修正顺序阅读。第一条提示词补“以账单为主”，减少创建目标的歧义，仍保持一句话。

合并主表、粒度变化和重复累计的说明，删去第二步末尾重复提醒；第三步直接承接“一账单一行”。保留建模 groupBy 与查询 groupBy 的阶段区别，验收段只收束连接键、唯一性与对账。

两段 JSON 压缩排版，内容与已执行 payload 不变。两个 QM 源码完整保留、各一次；四步仍为创建→查询→创建→查询。仅改文字与排版，不改模型或请求文件，不重跑引擎；验证沿用本轮已保存证据，未将提示词文字调整说成独立会话复验。

补充 ETL 预汇总与聚合 JOIN 的取舍

第三步先交代常见解决方案：ETL 将明细加工为账单粒度汇总表，再关联。说明汇总表、刷新和变更维护的成本，引出小数据量下查询时聚合的折中；不把 ETL 写成必需，也不承诺聚合 JOIN 必然更快。代码后删除重复的“无需预先生成汇总表”，保持提示词不变。

已复核既有 acceptance.json：逐账单 83 行、逐客户 47 行、两侧总额各 477.53，普通关联重复金额 4256.25。功能验证有实际 CLI 证据；ETL 维护成本为工程取舍说明，本轮没有搭建 ETL 或做性能对比。

ETL 取舍加入后的整体复审

主线保持“选主 TM 与结果粒度 → 普通 JOIN 看重复金额 → ETL 预汇总的成本 → QM 聚合 JOIN → 查询对账”。第三步直接承接账单粒度问题，压缩“一次对账增加整套流程”“本例先采用”等重复表述；ETL 与查询时聚合各说明一次代价，不写成前者必需或后者必然更快。

四步仍分两次创建、两次查询，四条提示词不变；建模前聚合与查询外层分组的区别继续保留。QM 源码和 JSON 未改，仅精简说明，沿用已验证结果，不重跑查询或追加性能测试。