小销售库样例

本样例使用自编虚构数据：5 位客户、11 张发票。金额以人民币分保存，日期使用同一时区的 YYYY-MM-DD HH:MM:SS 格式。第一章按有效发票总金额统计客户销售额。

将以下三个文件放在同一目录：

• seed.sql：建表和数据。
• chapter-01-top-customers.sql：六月客户销售额前三名查询。
• verify.py：使用 Python 自带 SQLite 运行并核对结果。

进入保存文件的目录后运行：

python -X utf8 verify.py

脚本在内存中建立练习库，不需要安装第三方 Python 包。结果输出到终端，同时保存到同目录的 chapter-01-results.json。

六月有效发票为 1002、1003、1004、1006、1007、1008。按客户逐笔累计，分别得到华东食品 5500 元、远山商贸 4200 元、青禾便利 3000 元、南桥百货 900 元，共 13600 元。正文查询返回前三名，合计 12700 元。

北辰超市的六月发票已经作废，因此没有进入排名。1007 的开票时间为六月最后一天 23:59:59，计入六月；1005 的时间为七月一日 00:00:00，计入七月。

七月前两名为远山商贸 9000 元、青禾便利 6000 元。

第 2 章明细关联与重复累计

第 2 章使用原有 11 张发票，另外增加 16 条商品明细。原始 seed.sql 保持原样。

将 seed.sql 与下列五个文件放在同一目录：

• 明细结构与数据。
• 错误关联查询。
• 先汇总后关联的查询。
• 同额发票练习。
• 第 2 章复跑脚本。

python -X utf8 verify-chapter-02.py

脚本分别在独立内存库中核对基础样例、同额发票练习及无明细发票边界，结果保存为 chapter-02-results.json。

错误关联把四位客户的金额变成华东食品 11000 元、青禾便利 6600 元、远山商贸 4200 元、南桥百货 1800 元。修正查询与第一章基线一致，并返回各客户明细条数 4、1、4、2。

同额发票练习给华东食品增加一张 3000 元发票，正确金额为 8500 元，SUM(DISTINCT 发票金额) 却只返回 5500 元。无明细边界另增一张北辰超市 1000 元的有效发票，用于核对 LEFT JOIN 和零明细条数；这些增量均不修改原始样例。

第 4、18、19 章的查询对照

这几章继续使用原始 seed.sql，不依赖第二章的明细增量。

• 第 4 章请求示例：产品无关的教学 DSL，包含语义模型标识、查询意图与返回条数，不对应具体产品 API。
• 第 4 章等价物理 SQL：展示语义模型定义落到物理表后的查询含义。
• 语义 SQL 专题教学示例：面向约定的虚拟业务表，不对应具体产品的 SQL 入口。
• 核对脚本：将以上三个文件与 seed.sql、第一章查询一起放在同一目录后运行。

python -X utf8 verify-query-equivalence.py

脚本在 SQLite 内存库执行物理 SQL，再创建临时视图模拟本例字段映射，执行语义 SQL 专题教学 SQL，与第一章基线比较。三者均返回华东食品 5500 元、远山商贸 4200 元、青禾便利 3000 元；结果写入 query-equivalence-results.json。

这里验证的是简单查询的含义和结果，以及请求 JSON 能否解析。未运行实际语义引擎的模型加载、DSL 校验、权限或 SQL 编译，临时视图也不实现复杂指标的语义。应用篇将建立真实模型并保留执行证据。