lasuar
4 天前
我的技术栈是 go 微服务，多年经验。
以我个人经验哈，不要去依赖工具的 migration api ，这在做项目迁移/重构时是噩梦，并且对于日常的表维护不够透明。当我希望查一个表结构时，我需要去数据库才能查到，通过代码始终是不直观的，部分开发者为了图方便有时候会绕过代码直接修改表结构，这就使得代码中的映射成为摆设，长期以往，这其中的工程复杂度是难以想象的。！
我项目中对于表维护的开发流程：
1. 对于新表，在项目根目录建立 `docs/`目录，以业务为名称建立`.sql`文件，其中可以存放业务相关的一张或多张表的原始 CREATE sql 。这些文件将受到版本控制！
2. 对于旧表的更改, 例如增删字段，首先修改文件中的 CREATE sql ，其次建立`docs/log/`子目录，在子目录中新建`yyyymmdd.sql`（时间为上线日期），其中存放用于上线日改表的 ALTER sql 。
3. 上线时，上线人员（这个一般不会给脚本操作）手动执行 sql ，以及其他更新服务步骤。
这样的好处：
1. 通过`docs/`目录可以直观的看到系统中有多少业务（建了表），每个业务建表数量开发人员是基本清楚的，所以整体来说也是一目了然；
2. 在需要做整体的表结构优化时，通过`docs/`目录可以快速浏览现有表的结构特征，并制定优化方案；
3. 在需要迁移时，直接执行`docs`目录下的所有 sql 文件即可。
4. 对于做了按日期/ID 拆分的表，CREATE SQL 中的表名也要加上类型的 pattern ，以便识别：`create table xxx_$yyyymm ...`；
5. 利好开发新人；
6. 不与开发语言绑定。极端情况下，使用其他语言重构服务时会减少很多不必要的麻烦；