如果数据库后期表字段修改了或者增加了， Mybatis 的实体类、Mapper 都要重新生成一遍吗？甚至一些修改的字段已经侵入到 service 层了，那是不是 service 层的代码也要进行修改呀？

就是因为这样所以才讨厌改需求，所以实际设计数据库过程，都会考虑增加备用字段，如果是有类似于经常改动的需求，就用非关系型数据库完事

不能砸地基。改动小就保留原有字段，更新 Entity Mapper 基本没事；改动大，就迁移到新表，旧的 Service 就废弃了。
做需求嘛，就是改数据库和代码。

用 Mybatis Plus 或者 JPA 吧。类加字段就好。mybatis 默认的生成器 xml, Mapper 很多写死的代码和类型。

是的。但是 service 层不应该隔离开么

加字段？我们这儿根本不用程序员骂，DBA 就能给你挡得死死的了。程序员想加个字段都跟杀 DBA 他全家似的，更何况需求方？

这世界本身就是变化的
需求跟随变化
代码就应该能响应变化，否则就会被淘汰


数据库的字段这些属于具体的实现了，我们要面对的是抽象，不是具体的细节

要知道不是面向数据库编程，而是面对业务

从来没有遇到过字段（名称和类型）要修改的问题，一般修改长度 OK ，这个应该是大忌。

然后新增字段很正常，我的做法是自动生成。然后自己扩展过 mybatis 的 generator 插件，可以自动做合并。

这不是 migration 框架处理的问题吗，这个也属于正常需求

JPA 改 entity 就好了

用 jooq 就好了，随便改，反正类型安全会报错
写到 xml 里还得一个个去对

我见过某些人设计的表一下留了 10 个备用字段

你想编写一次，到处运行？

我见过有一个表有两百多个字段，几十个索引，2000 多万的数据量，几乎每两周就要增加一个字段，技术负责人还不允许预留字段，加一个字段就需要从 countroller 开始一直加到 Mapper ，出错了就被骂

@zengguibo 曾经也有过这样的经历，当时我数据库设计的有问题，导致后面开发不得不频繁修改数据库。后面我直接多加了几个 varchar 字段当备用字段，完美解决字段不足的问题。

@mmdsun 那自动生成的 mapper 和 service 不用修改了是吧？

@Rocketer 字段合理不？长度合适不？别一上来就 varchar(2048)，text ，blob 什么的。如果是的话看到是挺讨厌的。还是说 DBA 还要给写 SQL ？写 SQL 直接写*？还是说口径是 DBA 那边出？

@kachu673 是的，不需要改。

> Mybatis 的实体类、Mapper 都要重新生成一遍吗？

要，如果用了 mybatis plus 之类的东西也许不用

> 甚至一些修改的字段已经侵入到 service 层了，那是不是 service 层的代码也要进行修改？
既然侵入到 service 了那就要改喽

> 有没有在不修改原有代码的基础上进行扩展的方法？
有，用 map 或者 object （逃）

加字段往往是为了支撑更复杂的业务，既然是扩展业务那么改 service 也就理所应当了…

只加字段,不删字段,不改字段,要不然你上线都没法平滑上线

@kachu673 这个备用字段名字怎么办？能对应上需求吗？

@waytodelay 备用字段，自然对不上需求

改 entity 和 mapper