业务字段定义变化了，数据库的字段要不要跟着变？

[jasongzj]

问题发生在店铺装修的场景上，装修的配置项是 json 格式存储的，第一版的时候业务侧给的定义是边距，于是字段用的 margin ，但是后来又做了细化，变成了内边距，这时 json 里存储的 margin 对应的就是内边距的值。

第三版的时候又增加外边距，这个情况下：

存量数据该不该把 margin 映射为 padding 呢？

还是另起一个字段表示外边距，沿用 margin 表示内边距呢？

如果很多业务字段都出现这个情况，是不是都要这么做呢？

[sqfphoenix]

数据分版本 v1alpha1 v1beta1 v1

[jasongzj]

@sqfphoenix 这种处理的话，前端需要保留多套处理逻辑的吧？

[8355]

为什么不重新起名?
映射需要频繁改动代码使复杂度提高 会明显提高 bug 率
全部场景你们测试能保证全部覆盖吗
其次 类似 app 的老版本应用会因为你数据的变更强制更新变得不可用丢失用户


如果是修复之前的错误 那么应该短暂停机或者部分业务停机手动刷数据 刷成正确 适用于业务代码不改动只是修改数据修复 bug 的情况

[zlowly]

见过几种做法，各有优劣。
1 、有一楼这种常见的数据分版本，应用重启后检查数据版本，需要升级则运行数据升级模块或脚本，将数据转换成新版本格式后再继续。业务逻辑代码只处理最新版本格式的数据。
2 、如果应用不可停机的话，通过常在新代码里做兼容性代码。但有可能在各个服务器 /容器部署升级新代码时，因为旧代码应用无法处理新版本数据，导致一段时间内有部分服务异常。
3 、在 2 基础上，数据格式冗余，保证新旧版本都不出错。看情况在新代码全部部署后，将数据在线更改为新格式去除冗余。基本保证应用可用性，需要处理过程较长较多，自然容易做多错多。

[tf2]

用传统 db 的思路来做，就得新建一个 view 。

[opengps]

开闭原则。对修改封闭，你想你历史数据可能一个 TB ，更新字段名可能需要锁表 30 分钟，你还敢更新吗？

[yinmin]

系统功能更新 /优化，存量数据一般不改字段名。如果是基于老系统开发新系统，是建议改字段名的。

[jasongzj]

谢谢各位建议，最终为了以后业务迭代理解起来更合理，加了一层数据处理层，保证旧数据映射到新字段上