MySQL 数据基础：关系、约束与订单查询｜课后复习
今天学会了什么
能逐行读取商品 CSV，用生成器分批输出复核清单；能把订单对象转换为关系表，用参数化查询取回订单明细和零订单客户。
沿图说明 JSON 保存如何迁移到关系表，再在自己的五表关系图上标出主键、外键和一对多；解释历史单价为何不能换成商品现价。
今天讲了什么（对照复习）
下面逐项对应课堂正文。先盖住右边那一栏，凭记忆回答；卡住了再翻回左边同名的小节。光说得出名字不算会，还要能讲清它会做什么、什么时候会失效。
| 课堂对应章节 | 必须能解释的机制与边界 |
|---|---|
| 为什么不继续用一个 JSON 文件；MySQL 在系统里的位置 | 多对象引用、跨表写入和并发使单文件方案受限。Server 执行 SQL 并管理数据；Client 是操作工具；PyMySQL 是驱动；SQLAlchemy 在驱动上提供映射和会话，四层不同。 |
| MySQL 第一次使用：安装、配置、连接、再写 SQL；本周数据库基线；入场检查 | 分别验证安装、服务、端口、SQL 和 Python 连接。课程基线是 MySQL 8.4、InnoDB、utf8mb4 与专用库账号；密码从配置读取。已有 5.7 的兼容证据不能代替 8.4，CHECK 是否执行需按版本核实。 |
| 五个对象怎样变成表；最小五表设计；订单头与订单项 | Customer→Order、Order→OrderItem、Product→OrderItem 都是一对多；课程 Inventory 与 Product 一对一。订单头保存汇总，明细保存商品行事实，库存区分 available_qty 与 reserved_qty。 |
| 主键、外键和约束；建表顺序为什么有要求 | 主键唯一且非空，外键约束引用有效；先建被引用表，再建依赖表。唯一性、非空和业务约束要实际失败验证，不能关闭外键检查来掩盖顺序问题。 |
| 为什么 OrderItem 要存价格快照；人民币金额跨层映射；DECIMAL(10,2) 怎么读 | 历史明细保存下单时名称和价格；Python Decimal、数据库 DECIMAL、API 两位小数字符串保持元单位。DECIMAL(10,2) 为总 10 位含小数 2 位，整数最多 8 位，不代表所有企业都适用。 |
| DDL、DML、DQL | DDL 定义表等结构，DML 写入／修改／删除，DQL 查询；先识别任务再选语句。练习 CRUD 时限定课程库和目标条件，不把结构修改混为普通查询。 |
| JOIN：把分开的表重新组合；INNER JOIN 和 LEFT JOIN | INNER JOIN 只保留匹配行；LEFT JOIN 保留左表，没有右侧匹配用 NULL。统计零订单客户时不能被内连接丢掉；用 COUNT(订单主键) 区分零条明细，注意筛选位置可能改变保留语义。 |
| 参数化 SQL 为什么是底线 | SQL 结构与参数值分开交给驱动；不以 f-string 拼接用户输入。参数化保护值的绑定，仍需验证业务输入和资源是否存在。 |
出了问题：怎么发现、怎么修、怎么验证
只在你自己那份课程副本或专用实验数据上复验，把改之前和改之后的真实结果都留下来。
| 风险／现象 | 提前预防 | 怎样发现 | 怎样处理 | 怎样复验 |
|---|---|---|---|---|
| 服务装好却无法执行 SQL | 按服务、端口、账号、库、驱动逐层检查 | 保留实际连接错误，确认目标版本与库 | 修对应层的配置，勿把密码贴入日志 | 同一账号能执行简单查询且 Python 可连接 |
| 无效外键或建表顺序错误 | 先列依赖关系和建表顺序 | 在课程库尝试引用不存在的主记录 | 先建被引用表，修正数据引用 | 非法引用被拒绝，合法五表关系可查询 |
| 金额漂移或历史订单随现价变 | 固定 DECIMAL 精度和快照字段 | 改商品现价再查旧明细，并检查类型 | 从订单快照取值，移除 float 中间转换 | 旧金额与类型不变，新查询符合合同 |
| 零订单客户被漏掉 | 先写应保留的左表对象 | 准备一名有订单与一名无订单客户 | 修正 JOIN、筛选和聚合口径 | 两名都出现，无订单计数为零 |
| SQL 拼接或版本约束虚有其表 | 绑定参数，记录数据库版本 | 用含引号的参数与非法约束值在实验库检查 | 改参数绑定，按目标版本验证约束 | 输入不改变查询结构，约束反例确实失败 |
本日新增 Python 知识怎样进入商城
Path/open/with、编码、CSV/JSON、iter/next/StopIteration、yield、生成器表达式、一次性消耗、惰性分批；保留 MySQL 关系、约束、JOIN 与参数绑定。它们共同支持“批量商品资料复核与订单关系查询”。我应能打开 import_products.py 指出每个机制的位置，并重跑 读取三件和五件商品；空输入；坏单价行号；批大小 2→3；同一生成器二次消费；零订单客户与无效外键。
| 风险 | 提前预防 | 怎样发现 | 怎样处理 | 怎样复验 |
|---|---|---|---|---|
| 生成器被提前耗尽 | 保留消费责任，不用 list 做随意日志 | 同一对象第二次遍历为空 | 重新创建读取器或一次消费内完成工作 | 改变商品数，核对总量 |
| 文件坏行与部分输出 | 输入输出分开，保留行号 | 消费到坏行时报错且输出不完整 | 丢弃本次部分输出并修数据重跑 | 坏行转绿，原 CSV 未被覆盖 |
闭卷自测
先自己答一遍，再去运行或翻回课堂核对；不确定的地方标出来，别用 AI 的答案顶掉你自己的第一次判断。
-
Server、Client、Driver、ORM 分别做什么？“安装完成”还缺哪几层运行证据？
-
画五表关系并解释主键、外键、建表顺序与 OrderItem 的价格快照。
-
DECIMAL(10,2) 的两个数字是什么？金额经过 Python、MySQL 和 API 时各是什么类型？
-
零订单客户为什么会被 INNER JOIN 丢掉？LEFT JOIN 后 COUNT(*) 与 COUNT(订单主键) 的含义相同吗？
-
参数绑定与字符串拼接的边界在哪里？本机 MySQL 5.7 通过为什么不能签署 8.4 的 CHECK 验收？
-
为什么同一个生成器第二次遍历为空？五件商品按两件一批，怎样证明最后一件没有丢失？坏行在什么时刻抛错？
再看一眼真实业务
回到有赞报表实际字段，将一行代表订单还是商品明细说清楚。自己的五表关系属于课程设计，不把运营截图当成平台真实数据库结构。
今天留下什么，下节课怎么接着用
同时保留商品导入器、JSONL 复核清单、坏行与二次消费结果，供下一日接入资源和事务边界。
保留五表关系图、建表与样本脚本、参数化查询、约束反例、零订单客户查询和真实连接记录。W02-D02 在同一模型上接入 Service、Session 和跨表事务。
真实 MySQL 不可用时可用受控替身继续理解规则，数据库结果标为待验证；今天不要求完成并发锁与性能调优。
补充交接：D02 沿用商品资料和关系表，学习资源收口与整笔订单回滚。本人 commerce_ops 每天增量合并，不用后一天骨架覆盖前一天实现。
MySQL 接入要求：用本人导入器把 data/new_products.csv 完整生成 JSONL，再通过提供的 commerce_ops/mysql_catalog_import.py 向专用实验库新增 P2001/P2002。按课件查询产品与库存，验证未上架、零库存、金额与重复编号拒绝；没有真实库时该项保持待验，不把文件输出当持久化完成。连接支架无需学生从零编写，D02 再拆解事务边界。