想必大家都遇到过这个经典问题，随着业务不断扩张，需求不断增加，一些数据库表开始不停的加字段，刚开始还好，后面越来越吃不消，表的含义已经不明，维护成本急剧增加。那么有什么办法解决这个问题呢？

首先，扩展业务最核心的规约应该是尽量少的对已有核心代码进行修改，尽量从底到上新增一套新业务流程代码。顺着这个思路，我们看看数据库该如何设计。

举个例子

某工厂有一套软件系统，一张核心表是“作业表”，对应每一条流水线作业，后来新增了一种作业方式，而且还多个了“监工”的角色，于是我们向表中加了两个字段，一个是标志位，标记新作业类型，一个是监工的用户id。
然后我们会在代码中嵌入一堆的if-else，因为要判断不同的作业类型，新作业类型有自己的业务逻辑。
包括歪哥在内，想必很多人都由于种种原因写过这样的代码。这种写法的坏处显而易见，首先就是对代码的侵入，可维护性大大降低，一个新接手的人可能需要大量的时间搞懂这种新作业的逻辑，无法专注于原本的核心业务逻辑。然后就是在大部分情况下，新分支的代码都是跑不到的，因为这种新需求往往只是针对少部分特定用户，放到数据库上来说，我们新加的监工用户id字段在大部分情况下都是空值，而新字段的加入同样破坏了作业表的原本表意。

真正的横向扩展

表中无底线的加字段行为就是虚假的横向扩展。换个思路，就着前面的例子，我们可以不改变原来的表，再增加一张新表（作业表2）用来存储新作业类型数据，代码层面上，从dao层到service，再到controller，再到前端页面，完全可以新写一套逻辑针对新业务需求。当然，有些重复的组件、工具等还是可以复用的。

这样做的好处也是显而易见，更加利于分工协作，不用担心不熟悉业务逻辑的人破坏原有代码，维护起来也很方便，一旦出了问题，在理想情况下，新代码删掉即可。

当然，凡事有利有弊，坏处就是可能会增加不少重复代码，开发工期、工作量肯定要远超加if-else这种方式，但从经验来看，后期绝对是利大于弊。

说到工期，那可能就要说服项目经理，放弃过分的“敏捷开发”思想，以及“这么点需求不是分分钟搞定么”的PUA说辞，一切为了写出更加“信达雅”的优秀代码。