如果数据库后期表字段修改了或者增加了,Mybatis 的实体类、Mapper都要重新生成一遍吗? 甚至一些修改的字段已经侵入到 service 层了,那是不是 service 层的代码也要进行修改? 有没有在不修改原有代码的基础上进行扩展的方法? 代码新人,一点小小的疑惑,勿喷。
如果数据库后期表字段修改了或者增加了,Mybatis 的实体类、Mapper都要重新生成一遍吗? 甚至一些修改的字段已经侵入到 service 层了,那是不是 service 层的代码也要进行修改? 有没有在不修改原有代码的基础上进行扩展的方法? 代码新人,一点小小的疑惑,勿喷。
|
AlphonesJul 2, 2023
1
就是因为这样所以才讨厌改需求,所以实际设计数据库过程,都会考虑增加备用字段,如果是有类似于经常改动的需求,就用非关系型数据库完事
|
|
ErroadJul 2, 2023
2
不能砸地基。改动小就保留原有字段,更新 Entity Mapper 基本没事;改动大,就迁移到新表,旧的 Service 就废弃了。
做需求嘛,就是改数据库和代码。 |
|
mmdsunJul 2, 2023
3
用 Mybatis Plus 或者 JPA 吧。类加字段就好。mybatis 默认的生成器 xml, Mapper 很多写死的代码和类型。
|
|
timepastJul 2, 2023
4
是的。但是 service 层不应该隔离开么
|
|
RocketerJul 2, 2023 via iPhone
5
加字段?我们这儿根本不用程序员骂,DBA 就能给你挡得死死的了。程序员想加个字段都跟杀 DBA 他全家似的,更何况需求方?😈
|
|
freefcwJul 2, 2023
6
这世界本身就是变化的
需求跟随变化 代码就应该能响应变化,否则就会被淘汰 数据库的字段这些属于具体的实现了,我们要面对的是抽象,不是具体的细节 要知道不是面向数据库编程,而是面对业务 |
|
66Zi2nJk5Z6mdtzjJul 2, 2023 via iPhone
7
从来没有遇到过字段(名称和类型)要修改的问题,一般修改长度 OK ,这个应该是大忌。
然后新增字段很正常,我的做法是自动生成。然后自己扩展过 mybatis 的 generator 插件,可以自动做合并。 |
|
dayeye2006199Jul 2, 2023 via Android
8
这不是 migration 框架处理的问题吗,这个也属于正常需求
|
|
chihiro2014Jul 2, 2023
9
JPA 改 entity 就好了
|
|
knightdfJul 2, 2023
10
用 jooq 就好了,随便改,反正类型安全会报错
写到 xml 里还得一个个去对 |
|
murmurJul 2, 2023
11
我见过某些人设计的表一下留了 10 个备用字段
|
|
daimubaiJul 2, 2023
12
你想编写一次,到处运行?
|
|
zengguiboJul 2, 2023
13
我见过有一个表有两百多个字段,几十个索引,2000 多万的数据量,几乎每两周就要增加一个字段,技术负责人还不允许预留字段,加一个字段就需要从 countroller 开始一直加到 Mapper ,出错了就被骂
|
|
14
@zengguibo 曾经也有过这样的经历,当时我数据库设计的有问题,导致后面开发不得不频繁修改数据库。后面我直接多加了几个 varchar 字段当备用字段,完美解决字段不足的问题。
|
|
rioufbiJul 2, 2023
16
@Rocketer 字段合理不?长度合适不?别一上来就 varchar(2048),text ,blob 什么的。如果是的话看到是挺讨厌的。还是说 DBA 还要给写 SQL ?写 SQL 直接写*?还是说口径是 DBA 那边出?
|
|
chendyJul 2, 2023
18
> Mybatis 的实体类、Mapper 都要重新生成一遍吗?
要,如果用了 mybatis plus 之类的东西也许不用 > 甚至一些修改的字段已经侵入到 service 层了,那是不是 service 层的代码也要进行修改? 既然侵入到 service 了那就要改喽 > 有没有在不修改原有代码的基础上进行扩展的方法? 有,用 map 或者 object (逃) 加字段往往是为了支撑更复杂的业务,既然是扩展业务那么改 service 也就理所应当了… |
|
layxyJul 3, 2023
19
只加字段,不删字段,不改字段,要不然你上线都没法平滑上线
|
|
waytodelayJul 3, 2023
20
@kachu673 这个备用字段名字怎么办?能对应上需求吗?
|
|
21
@waytodelay 备用字段,自然对不上需求
|
|
iiainJul 4, 2023
22
改 entity 和 mapper
|