› MySQL 5.5 Community Server
› MySQL 5.6 Community Server
› Percona Configuration Wizard
› XtraBackup 搭建主从复制
Great Sites on MySQL
› Percona
› MySQL Performance Blog
› Severalnines
推荐管理工具
› Sequel Pro
› phpMyAdmin
推荐书目
› MySQL Cookbook
MySQL 相关项目
› MariaDB
› Drizzle
参考文档
› http://mysql-python.sourceforge.net/MySQLdb.html
MySQL 相关项目
› MariaDB
› Drizzle
参考文档
› http://mysql-python.sourceforge.net/MySQLdb.html
这是一个创建于 691 天前的主题，其中的信息可能已经有所发展或是发生改变。
问题发生在店铺装修的场景上，装修的配置项是 json 格式存储的，第一版的时候业务侧给的定义是边距，于是字段用的 margin ，但是后来又做了细化，变成了内边距，这时 json 里存储的 margin 对应的就是内边距的值。
第三版的时候又增加外边距，这个情况下：
存量数据该不该把 margin 映射为 padding 呢？
还是另起一个字段表示外边距，沿用 margin 表示内边距呢？
如果很多业务字段都出现这个情况，是不是都要这么做呢？
 |
1
sqfphoenix 2023-02-08 11:12:48 +08:00
数据分版本 v1alpha1 v1beta1 v1
|
 |
2
jasongzj OP @sqfphoenix 这种处理的话，前端需要保留多套处理逻辑的吧？
|
 |
3
8355 2023-02-08 12:11:43 +08:00
为什么不重新起名?
映射需要频繁改动代码使复杂度提高 会明显提高 bug 率 全部场景你们测试能保证全部覆盖吗 其次 类似 app 的老版本应用会因为你数据的变更强制更新变得不可用丢失用户 如果是修复之前的错误 那么应该短暂停机或者部分业务停机手动刷数据 刷成正确 适用于业务代码不改动只是修改数据修复 bug 的情况 |
 |
4
zlowly 2023-02-08 14:37:31 +08:00  1
见过几种做法，各有优劣。
1 、有一楼这种常见的数据分版本，应用重启后检查数据版本，需要升级则运行数据升级模块或脚本，将数据转换成新版本格式后再继续。业务逻辑代码只处理最新版本格式的数据。 2 、如果应用不可停机的话，通过常在新代码里做兼容性代码。但有可能在各个服务器 /容器部署升级新代码时，因为旧代码应用无法处理新版本数据，导致一段时间内有部分服务异常。 3 、在 2 基础上，数据格式冗余，保证新旧版本都不出错。看情况在新代码全部部署后，将数据在线更改为新格式去除冗余。基本保证应用可用性，需要处理过程较长较多，自然容易做多错多。 |
 |
5
lambdaq 2023-02-08 14:38:27 +08:00
用传统 db 的思路来做，就得新建一个 view 。
|
 |
6
opengps 2023-02-08 21:39:03 +08:00 via Android
开闭原则。对修改封闭，你想你历史数据可能一个 TB ，更新字段名可能需要锁表 30 分钟，你还敢更新吗？
|
 |
7
yinmin 2023-02-12 19:23:24 +08:00
系统功能更新 /优化，存量数据一般不改字段名。如果是基于老系统开发新系统，是建议改字段名的。
|
|
8
jasongzj OP 谢谢各位建议，最终为了以后业务迭代理解起来更合理，加了一层数据处理层，保证旧数据映射到新字段上
|
Select Language