场景

我们有多种类型订单：实物订单、特享商户订单、核销订单、生活缴费订单、电影票订单、机票订单、以及以后会持续新增的未知类型订单，它们都存放在不同的订单类型表中

影响

导致有些业务做起来会比较痛苦

比如：

统计当前用户未付款订单总数

统计各类订单中该用户未支付的订单数

计算总数量

在列表中显示当前用户在某个时间段内所有未支付订单的信息(实现方式如上)

统计各类订单中该用户在这个时间段内所有未支付的订单信息

在业务代码里面进行按时间排序(这里还会有各种订单里面的相同字段信息可能会不同命名造成业务代码里面的转换[如：核销订单叫order_id，生活缴费订单叫orderId]，将要根据订单类型来分别判断..............各种痛苦)

例外还会有个未知因素：持续新增的未知类型订单

每新增一种内型订单，上面的实现都将随之新增业务代码。各种蛋疼。

思路

上次换工作，面试遇到一道面试题，如下：

"请设计数据库，用来存放 老师、学生等人员的信息，尽量满足以后的扩展。(提示：请写出3种方式，并分别写出优缺点)"

1.入门实现

思路：设计一张表，用来存放人员信息，定义type字段，用来区分老师 和 学生

优点：简单，能应对以后的各种查询

缺点：数据冗余字段太多，查询速度慢

2.常见的实现

思路：设计两张表：一张存放老师、一张存放学生(最常见的方式)

优点：都这样搞，优点自然多多

缺点：某些查询有些难以实现。(如：查询最近一个时间段的新加入的老师和学生并按时间排序)

3.面向对象的方式来实现

思路：设计3张表：人员表、老师特有属性表、学什特有属性表

优点：以上两种方式的优点总和

缺点：未知

解决方案

转回来看 我们商城的订单表跟上面的无比相识，目前是使用第二种方式来实现，导致有些业务做起来有些不是很爽

如果换种方式按第三种方式来实现，一切又将美好起来。

第三种方式使用面向对象的方式来实现：

先把所有订单的公有的属性抽象集合起来(如：订单编号、下单时间、订单状态、订单类型等)创建一张父订单表

创建各种订单专有属性表(各类订单特有属性)

关系：父类订单表 与 订单表 一对一的关系(每张订单表里面都能在父订单表里面有1条与之对应)

以上方式将能满足绝大多数业务情况

如上面的两种查询情况：

统计各类订单中该用户未支付的订单数

在列表中显示当前用户在某个时间段内所有未支付订单的信息

这里实现起来因为都能在父订单表中获取到，将会无比 easy，业务代码里面的排序、字段转换等问题也迎刃而解

优点

实现业务需求能力强

可扩展性的特点，以后新增一种内型订单，只需要在父订单表中给订单类型新增个值，在新增加张订单特有属性表

业务代码将改动小或者不用改动