标签：
场景
我们有多种类型订单：实物订单、特享商户订单、核销订单、生活缴费订单、电影票订单、机票订单、以及以后会持续新增的未知类型订单，它们都存放在不同的订单类型表中
影响
导致有些业务做起来会比较痛苦
比如：
例外还会有个未知因素：持续新增的未知类型订单
每新增一种内型订单，上面的实现都将随之新增业务代码。各种蛋疼。
思路
上次换工作，面试遇到一道面试题，如下：
"请设计数据库，用来存放 老师、学生等人员的信息，尽量满足以后的扩展。(提示：请写出3种方式，并分别写出优缺点)"
1.入门实现
思路：设计一张表，用来存放人员信息，定义type字段，用来区分老师 和 学生
2.常见的实现
思路：设计两张表：一张存放老师、一张存放学生(最常见的方式)
3.面向对象的方式来实现
思路：设计3张表：人员表、老师特有属性表、学什特有属性表
解决方案
转回来看 我们商城的订单表跟上面的无比相识，目前是使用第二种方式来实现，导致有些业务做起来有些不是很爽
如果换种方式按第三种方式来实现，一切又将美好起来。
第三种方式使用面向对象的方式来实现：
以上方式将能满足绝大多数业务情况
如上面的两种查询情况：
这里实现起来因为都能在父订单表中获取到，将会无比 easy，业务代码里面的排序、字段转换等问题也迎刃而解
优点
标签：
原文地址：http://www.cnblogs.com/zourui4271/p/4904599.html
