@cooltechbs 大部分项目，不管是技术栈熟悉程度还是事务的方面，类 MySQL 数据库都是避不开的。

通过我说的方式来记录表结构，还有一个优势就是我不需要去完全学会那些 orm 库的各种 tag 语法。我个人认为哈，这东西完全对开发人员是一个多余的学习成本，虽然并不复杂，但是你耐不住他语法足够多还在不断更新，完全不利好语言新人。
而且这玩意和语言绑定，我最讨厌和什么东西绑定了，我现在的一个微服务项目没有使用任何框架，就是 go 加上 grpc ，注册发现都是直接用的 k8s 的 service ，做到足够简洁，如果有开发新人，他不需要学习额外太多东西。

@lasuar #9 纠正个小错误，是`docs/sql`目录，而不是直接的`docs/`目录。

@liuhan907 #10 首先哈，现代化的 IDE 可以帮助你写 SQL ，其次需要维护的 SQL 都是简单的 DDL sql ，并不复杂。最后哈，基本的 sql 能力是开发人员的必备项。

我的技术栈是 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. 不与开发语言绑定。极端情况下，使用其他语言重构服务时会减少很多不必要的麻烦；

参考 #18 ，毕竟年假还能换钱，能不请就不请

你本来就不该代劳，或者在代劳的时候，就提前说明原来的人干嘛去了，你不熟悉不知道不负责

上周看的毒液，放松还行

@justlazydog #5 开店先准备 个 8w 10w ，咋的，这不是钱啊

苦力也可做散工吧，这么干，迟早趴下

你自己都察觉不合理了，还问。

你反正是 gap ，可以小试一个月

你后来 多数据库的一致性问题呢

做 CRUD 的人当然觉得不是技术，做高性能或偏底层开发的才会觉得是技术；没有人强迫你一直 CRUD 。

登高山，行长路，至远方，观世界。