比如 migration 之前只有 posts 表，字段只有 body。
现在添加 users 表，并注册了一个 user。
然后想给 posts 表添加 user_id，全部更新为这个唯一的 user。
最终要在 db 层面去掉 default value 和 nullable。
更麻烦一点的场景：测试环境和生产环境这个 user 的 id 不一样。
怎么组织更新步骤？需要几个 migration？是否（何时）需要在 migration 之外手动更新数据表？
5 月 31 日更新
发现 rails migration 的 references 类型默认就是 nullable，非空检察由 rails 框架完成（belongs_to），不需要添加“在 db 层面去掉 default value 和 nullable”这一步。
Rei
#1
2019年05月27日
这种不一致的数据迁移我会单独写一个脚本，migration 只管模式迁移。
我习惯一个迁移包含一个任务，顶楼情况，增加 user 表和添加 user_id 是一个任务（增加 User Model），去掉 default value 是另一个任务（这跟 User 有关吗？）。
总结来看，这样的一次发布会包含两个 migration 和一个数据更新。
post 不包含 user_id 的旧业务逻辑
- migration 1：posts 添加 user_id (nullable, default null)（以及创建 users 表）
- 执行更新脚本：把所有 posts 的 user_id 更新到一致状态
post 包含 user_id 的新业务逻辑
- migration 2：posts 的 user_id 去掉 nullable 和 default null
执行更新脚本之前，到 post 包含 user_id 的新业务逻辑发布的这段时间，为了防止空 user_id 的新 post 产生，需要停机，我这样理解对吗？
对
xinyifly
回复
xinyifly
回复
不需要停机。
- 先执行 migration 1，创建 users 表，添加 user_id 到 posts 表
- 在你的 rails 应用中增加一个逻辑：创建 post 时设置 user_id；
- 跑脚本，更新 posts 的 user_id
- 执行 migration 2