java mysql 订单表设计

        最近由于系统日益复杂的需求系统中各种类型订单越来越多，原来的这些订单表已经不能满足当下的需求，以可扩展为目标打算对这些订单表进行重构，本文只涉及基础版的设计，对于高并发、分布式等暂不考虑。

        之前的系统订单按不同业务有不同的订单表，比如洗车订单表、喷漆订单表、内饰清洗订单表等。在网上找了一些订单的设计方案，也跟朋友讨论了一下几个设计方案的情况得出如下几个结果。

方案一：

保持原来的结构不变，每增加一种新的业务需求，就创建对应的订单表，然后将所有订单表合并为一个视图，查询的操作都在视图进行。

利：数据库不需要大的变动，不会影响现有的程序和数据，稳定性比较好

弊：订单数据的增删改比较麻烦，设计系统的时候会比较复杂，也容易出错。每增加一个业务需求，就需要添加新的订单表，然后加入到视图中去，还要开发对应的程序，非常不推荐。

方案二：

既然都是要改，那就不考虑大改还是小改了。分析这几种订单，然后将通用的字段拿出来作为订单基础表（比如订单号、订单状态、用户id、订单类型、价格、时间等订单表共有的，订单的增删改都在这个表上进行），然后将每个订单独有的一些字段再创建订单明细表（明细表一般不涉及删除和修改），明细表分别对应各自的业务需求。

利：订单数据比较清晰，增删改只需操作订单基础表，系统设计会比较精简，扩展性较高

弊：新增一个业务需求，可能需要添加对应的订单明细表，程序中也要添加一部分操作。另外可能就是维护这些订单明细表稍微麻烦点。

方案三：

说到方案三不得不说一下mysql5.7的一个新特性json列，就是mysql可以将一列作为json类型存储数据。那这样的话我们可以将方案二中订单明细表都作为一个json列存入订单基础表中，这样所有的订单信息都存在订单基础表，一个表就可以完成不同业务的订单。

利：新增业务需求，订单表和程序基本不需要什么太大的变动，不需要维护这些订单明细表。

弊：首要使用json列必须是mysql5.7以上的版本，然后json列的数据操作起来感觉有点麻烦，不友好，所以json列的数据最好只查询用。

另外json列可以用字符串替换，直接用字符串存json列，但是这样数据操作起来还不如json，只是理论上可行。暂时想到这么几种方案，具体使用哪种需要根据自己系统的需求，不要硬套，因为我这些是根据我的系统需求做的，只是提供几种思路，仅供参考。