场景
我们有多种类型订单：实物订单、特享商户订单、核销订单、生活缴费订单、电影票订单、机票订单、以及以后会持续新增的未知类型订单，它们都存放在不同的订单类型表中
影响
导致有些业务做起来会比较痛苦
比如：
- 统计当前用户未付款订单总数
- 在列表中显示当前用户在某个时间段内所有未支付订单的信息(实现方式如上)
例外还会有个未知因素：持续新增的未知类型订单
每新增一种内型订单，上面的实现都将随之新增业务代码。各种蛋疼。
思路
上次换工作，面试遇到一道面试题，如下：
"请设计数据库，用来存放 老师、学生等人员的信息，尽量满足以后的扩展。(提示：请写出3种方式，并分别写出优缺点)"
1.入门实现
思路：设计一张表，用来存放人员信息，定义type字段，用来区分老师 和 学生
- 优点：简单，能应对以后的各种查询
- 缺点：数据冗余字段太多，查询速度慢
2.常见的实现
思路：设计两张表：一张存放老师、一张存放学生(最常见的方式)
- 优点：都这样搞，优点自然多多
- 缺点：某些查询有些难以实现。(如：查询最近一个时间段的新加入的老师和学生并按时间排序)
3.面向对象的方式来实现
思路：设计3张表：人员表、老师特有属性表、学什特有属性表
- 优点：以上两种方式的优点总和
- 缺点：未知
解决方案
转回来看 我们商城的订单表跟上面的无比相识，目前是使用第二种方式来实现，导致有些业务做起来有些不是很爽
如果换种方式按第三种方式来实现，一切又将美好起来。
第三种方式使用面向对象的方式来实现：
以上方式将能满足绝大多数业务情况
如上面的两种查询情况：
这里实现起来因为都能在父订单表中获取到，将会无比 easy，业务代码里面的排序、字段转换等问题也迎刃而解
优点
- 实现业务需求能力强
- 可扩展性的特点，以后新增一种内型订单，只需要在父订单表中给订单类型新增个值，在新增加张订单特有属性表
- 业务代码将改动小或者不用改动