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

• 資深大佬 : lscho

  没办法，字段多了就分表

• 資深大佬 : infun

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

• 資深大佬 : SimonOne

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

• 資深大佬 : ericgui

  业务乱，这又不是技术问题，这个你作为程序员怎么可能解决得了？
  不要幻想代码可以解决一切问题，代码只是现实生活的一个在互联网上的一个映射 /投影，而且你在写代码的时候又要做很多抽象，抽得四不像的情况多的去了
  跑吧

• 資深大佬 : Samuelcc

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

• 資深大佬 : dajj

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

• 資深大佬 : eason1874

  一步到位是消费主义的谎言.jpg
  后期发展谁说得准呢，不需要过度设计，有一定设计预留就够了
  后期差异太大再分开，重新设计 AB 两张表，迁移或者根据券码、时间决定读新表还是旧表

• 資深大佬 : clf

  （快进到 text 存 json 字符串）

• 資深大佬 : Ariver

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

• 資深大佬 : ospider

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

• 資深大佬 : ZhaoWang

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

• 資深大佬 : xuanbg

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

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

• 資深大佬 : pengtdyd

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

• 資深大佬 : Saxton

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

• 資深大佬 : sadfQED2

  @clf 基操，勿 6

• 資深大佬 : zeni123

  BigTable 架构啊

• 資深大佬 : liuxu

  解决掉建表的人

• 資深大佬 : 3dwelcome

  说起来可能主不信，但我个人推荐的方式就是对数据套娃。
  也就是对数据库建立一个抽象层的读写 API ，给后端数据库读取的数据，都是加工处理过后的。
  对外看起来是两个表，读写也是两个表。实际存到磁盘上，可能就一个总表了，通过一些代码做逻辑字段的切分。

• 資深大佬 : akira

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

• 資深大佬 : zachlhb

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

• 資深大佬 : netnr

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

• 資深大佬 : yogogo

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

• 資深大佬 : php01

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

• 資深大佬 : goldpumpkin

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

• 資深大佬 : bsg1992

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