逻辑模式与迁移计划

先把问题放回真实系统

我们不从术语表开始。设想你正在维护一个已有用户、并发请求和历史数据的系统，今天必须对“逻辑模式与迁移计划”作出设计决定。一个选择看起来能跑，并不表示它在重复数据、NULL、并发、崩溃或规模扩大后仍正确。上一节建立了本章的语言，本节把它推进到可执行判断。本节真正要回答的是：怎样把直觉写成数据库能够执行、我们能够反查的规则。

先给出本节主张：从 ER 与依赖得到逻辑模式后，还要给版本迁移、回填、双读写边界和回滚；生产变更不能假设停机重建。这句话包含对象、约束和结果三层。学习时请分别圈出“我们在研究什么”“什么条件不能省”“成功时能保证什么”。如果只记最后一个名词，遇到题目换一张表就会失效；如果能把三层说清，SQL 语法变化也不会妨碍推理。

机制：从状态、操作到可验证结果

把数据库看成状态 $D$。一次读操作从 $D$ 提取满足条件的关系，一次写操作把 $D$ 变为 $D^{\prime }$。本节的核心规则是：迁移每一步应向前兼容当前与相邻版本，并有行数、校验和及回滚点。它不是装饰性公式，而是一份检查清单：先确认输入对象和粒度，再列成立条件，随后执行变换，最后核对输出模式、行数、单位或不变量。

针对“逻辑模式与迁移计划”，第一步先写一句“一行代表什么”，第二步标出键、谓词或事务边界，第三步预测结果数量与失败情形，第四步才运行 SQL 或实验。数据库题最常见的失误不是少写一个关键字，而是从一开始就把结果粒度、量词或可见性理解错了。机制推演必须能解释成功样例，也必须能解释一个反例为何被拒绝。

完整例子：边做边验

考虑这个场景：把 order.status 拆成状态历史表：先建新表、回填、双写校验、切读、停止旧写，最后延迟删除旧列。先不要急着提交答案。请在草稿上列出初始表、候选键和目标输出；如果涉及并发，再列出两个事务的操作顺序；如果涉及成本，再把记录数换算成页数或中间结果行数。随后按“迁移每一步应向前兼容当前与相邻版本，并有行数、校验和及回滚点”逐项执行。每完成一步就问：结果中的一行现在代表什么？是否出现重复？NULL 会怎样？失败发生在此处时能否恢复？

一个合格的“逻辑模式与迁移计划”演算应同时留下三类证据。其一是结果证据，例如确定的行集合、数值、查询计划或事务历史；其二是边界证据，要从“把 order.status 拆成状态历史表：先建新表、回填、双写校验、切读、停止旧写，最后延迟删除旧列”继续构造空表、重复键、并列值、网络超时或崩溃点；其三是解释证据，即为什么本节规则“迁移每一步应向前兼容当前与相邻版本，并有行数、校验和及回滚点”能支持所选算子、索引、隔离或恢复策略。只展示最终截图，无法区分理解与偶然成功。

在线练习：先预测，再运行，再解释

请先完成“逻辑模式与迁移计划”绑定的单选题，识别“从 ER 与依赖得到逻辑模式后，还要给版本迁移、回填、双读写边界和回滚；生产变更不能假设停机重建”中的必要条件；再完成多选题，把完整证据链与听起来正确的口号分开；最后按“迁移每一步应向前兼容当前与相邻版本，并有行数、校验和及回滚点”完成计算或 SQL 推演题，提交步骤与结论。若本章附有 Python sqlite3 代码关卡，还要从标准输入建立内存数据库并通过不少于四组测试，不能用伪代码冒充运行结果。

围绕“把 order.status 拆成状态历史表：先建新表、回填、双写校验、切读、停止旧写，最后延迟删除旧列”的自主练习也按三轮做。第一轮不运行，手算结果和行数；第二轮在 SQLite 中创建能核验“逻辑模式与迁移计划”的最小数据，至少含正常、空值、重复企图和边界四类样例；第三轮故意破坏“迁移每一步应向前兼容当前与相邻版本，并有行数、校验和及回滚点”中的一个连接条件、约束或事务顺序，观察错误如何暴露。把预测与实际不一致之处记入课程笔记，这比抄一遍正确 SQL 更有价值。

易错点与调试路线

学习“逻辑模式与迁移计划”时最危险的捷径，是看到熟悉词就套固定写法，却没有核对本题的键、基数、NULL 语义、工作负载或故障模型。调试时不要同时改很多地方：先缩成最小反例，打印每个中间关系的模式与行数；再检查约束是否真的生效；最后比较计划或并发历史。每次修改只验证一个假设，并保留修改前后的证据。

“逻辑模式与迁移计划”还有一个工程边界要记住：数据库替我们执行声明的规则，却不能猜出没有声明的业务语义。本节所说的“从 ER 与依赖得到逻辑模式后，还要给版本迁移、回填、双读写边界和回滚；生产变更不能假设停机重建”若只存在产品经理脑中，任何索引或隔离级别都不会自动补上它。应根据“迁移每一步应向前兼容当前与相邻版本，并有行数、校验和及回滚点”把规则落为唯一键、检查约束、事务条件、触发器或可审计的应用协议，并为拒绝路径写测试。

自检与本节收束

合上页面，用自己的话回答四问：一，“逻辑模式与迁移计划”处理的对象是什么；二，规则“迁移每一步应向前兼容当前与相邻版本，并有行数、校验和及回滚点”依赖哪些条件；三，在例子“把 order.status 拆成状态历史表：先建新表、回填、双写校验、切读、停止旧写，最后延迟删除旧列”中，哪一步最容易得到表面正确但语义错误的结果；四，怎样用一个反例推翻错误实现。任何一问说不完整，都应回到机制或实验，而不是继续背下一页。

下一节会在这个结论上继续增加一个约束或更真实的系统条件。回看“逻辑模式与迁移计划”，你应该带走的不是一串孤立名词，而是一种稳定动作：围绕“从 ER 与依赖得到逻辑模式后，还要给版本迁移、回填、双读写边界和回滚；生产变更不能假设停机重建”定义粒度，声明不变量，按“迁移每一步应向前兼容当前与相邻版本，并有行数、校验和及回滚点”推演机制，用最小数据运行，再用反例和故障检查边界。这套动作会贯穿关系模型、SQL、索引、优化、事务、恢复和分布式数据库。