业务快速迭代需要修改数据库表结构，有办法能避免服务频繁重启吗？

[LeeReamond]

非微服务架构，没有那么庞大的需求。但是这个需求在设计上需要经常修改表结构，比如商品对象未来可能会不断新增一些附加属性（假设目前每行需要保存对象的文件地址、文件大小、修改时间等等，未来可能会根据需求不断新增作者 id ，作者备注等等，大概类似这种情况）

在这个需求下最初建表的时候不可能设计出未来所有可能出现的项目，而每次新增项目都要调整表结构，这又涉及到服务重启，还有如果有正在处理的链接那表还有上锁的等等问题。。有什么设计上的经验可以比较好的处理，避免各种凌晨三点维护重启服务的情况吗？

========

目前想到一种方法是专门搞一个追加项目表，里面一共四项，分别是(追加项目 id ，链接的原始项目 id ，追加项目名称，追加项目内容)。但是这么搞的话随着数据量无限增大，感觉处理读取需求时系统会被拖到非常慢，不是一个可行的方案。

[AS4694lAS4808]

数据库改了对应的代码也改了吧？那不是需要重启服务部署吗。。？还是要动态的读取数据库列？然后把读出来的列名直接显示为数据的名称？

[LeeReamond]

@AS4694lAS4808 读取是很简单的，网关方面更新的话也不用停机，只是不知道数据库应该咋搞

[des]

经常修改的字段？那不就是 json 了？

[neptuno]

额外添加的字段存 json ，然后 apollo 动态读取配置，通过配置去解析存储到数据库

[wowo243]

试试非关系的数据库，比如 mongo ？

[lower]

我见过的大部分 cms 都是这么搞的，扩展 /自定义模型……
表结构有点类似数据库 schema 表，存取都得做一些解析处理；

也许你可以考虑不要用传统关系型数据库了。。

[opengps]

表结构级别的变更还是尽量避免吧，用扩容新表等方式取代，避免触碰原有结构的调整

[sadfQED2]

目测你应该是 MySQL ，动态 DDL 有很多很成熟的方案了

[LeeReamond]

@lower 头疼，关系型数据库还是好用啊，取某范围数据的某字段之类的，还有连表。存 kv 数据或者关系型数据库里存 json 的话相当于抛弃了关系型的好处，所以每次读取一个字段都需要读取并解析全库

[johopig]

看起来只是新增列的操作，动态读取配置，然后直接执行 Online DDL 的影响是很小的

[3dwelcome]

和 6 楼一样，我也看过很多 cms 自己弄一套 schema ，来应对不断变化的需求。

就是为了能动态扩展字段数量。

[guisheng]

一个主备加定时启动脚本加短信通知是不是就好了…… 本来就是单体服务这样弄下去可维护性会比较差吧

[oneisall8955]

竖表横表？

[golangLover]

这是你们管理的问题，不是技术问题。哪有天天加 field 的。如果经常加 field ，只是证明管理的规划很差