平时开发中，业务膨胀导致表结构臃肿，一般怎么解决，有什么方法论？

没办法，字段多了就分表

一百九十多个字段的表都没拆，还在加。。。

B 加字段
XX 国企信息管理部评估：表里不就有这个字段了吗？
答：那时 A 的业务字段，我不能乱用，码值都不一样，只是看着像是一个字段
XX 国企信息管理部评估：不管，有字段就不能再加，驳回，就用这个字段

WRNM

业务乱，这又不是技术问题，这个你作为程序员怎么可能解决得了？

不要幻想代码可以解决一切问题，代码只是现实生活的一个在互联网上的一个映射 /投影，而且你在写代码的时候又要做很多抽象，抽得四不像的情况多的去了

跑吧

我在小规模服务中用过 Mongodb 存储多态对象，能够比较优雅地解决这种问题。但是没在大规模服务中尝试过。

换项目组或者换公司就好了

一步到位是消费主义的谎言.jpg

后期发展谁说得准呢，不需要过度设计，有一定设计预留就够了

后期差异太大再分开，重新设计 AB 两张表，迁移或者根据券码、时间决定读新表还是旧表

（快进到 text 存 json 字符串）

银行有很多一个表字段六七百。

@clf mysql 5.7 前这也是传统艺能了

垂直拆分成两张，业务自定义垂直表，随便他们折腾

@eason1874 设计要有前瞻性，做到能升级、易升级就行了。但不需要预留现在没用的东西，特别是那种从 c0-c99 的预留未定义字段，简直就是辣鸡中的战斗机。

任何读写都通过一个 dataview 来进行，这个 dataview 用来组织表格，如果有加不了的项，就拆到另一个表中去，用 dataview 来组织这些表，最终呈现一个“统一”的表格给应用，当然，注意要加上一个版本号，以便数据使用方来识别。所有写入都要通过一个写入过程，在过程中来判断要写入那些表中的那些字段，以便分开加锁，这样还能提高性能。

把该死的架构师拉出去祭天就可以了

考虑自定义字段？ 用行来存字段呗，不一定要把字段具体化

@clf 基操，勿 6

BigTable 架构啊

解决掉建表的人

说起来可能楼主不信，但我个人推荐的方式就是对数据套娃。

也就是对数据库建立一个抽象层的读写 API ，给后端数据库读取的数据，都是加工处理过后的。

对外看起来是两个表，读写也是两个表。实际存到磁盘上，可能就一个总表了，通过一些代码做逻辑字段的切分。

忍受不了的时候 就拆表呀。。

分表，先建一个券主表存放通用字段，然后每种券独立到自己的表中，然后根据主表的券类型去各类型表中查扩展数据

就举例需求来讲，首先分 1 和 2 ，然后 1 又拆分 11 12 13 ，2 就拆分 21 22 23 ，如果还需要分，那就转成字符串，1-1-1 2-1-1 这种
也算是一种可扩展的变通，当然涉及到的逻辑也要改，历史数据的维护(很多时候不愿意维护历史数据来支持新的功能，而是通过加字段，反而越来越复杂)

我现在是这样做的，券有一个主表，里面是券的基本信息，id ，编号，名称，类型，假设券类型分 A 和 B ，再建两张类型表 A 和 B ，这样就分开 A 和 B 的类型字段就各自维护，主表也能保持简单，后续有新类型就新增类型表就行了

不要对重构抱有敌意，拥抱重构，才能前进

@SimonOne 直接换个英文单词 换一个解释， 绕晕它

继续加字段
如果字段是在太多就只能分表
分表也回带来业务上开发的复杂度