用面向对象的思路建设计数据库

场景

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

影响

致使有些业务作起来会比较痛苦

好比：

• 统计当前用户未付款订单总数
  1. 统计各种订单中该用户未支付的订单数
  2. 计算总数量
• 在列表中显示当前用户在某个时间段内全部未支付订单的信息(实现方式如上)
  1. 统计各种订单中该用户在这个时间段内全部未支付的订单信息
  2. 在业务代码里面进行按时间排序（这里还会有各类订单里面的相同字段信息可能会不一样命名形成业务代码里面的转换[如：核销订单叫order_id，生活缴费订单叫orderId]，将要根据订单类型来分别判断..............各类痛苦）

例外还会有个未知因素：持续新增的未知类型订单
每新增一种内型订单，上面的实现都将随之新增业务代码。各类蛋疼。

思路

上次换工做，面试遇到一道面试题，以下：

请设计数据库，用来存放 老师、学生等人员的信息，尽可能知足之后的扩展。（提示：请写出3种方式，并分别写出优缺点）

1. 入门实现

   思路：设计一张表，用来存放人员信息，定义type字段，用来区分老师 和 学生
   - 优势：简单，能应对之后的各类查询
   - 缺点：数据冗余字段太多，查询速度慢

2. 常见的实现

   思路：设计两张表：一张存放老师、一张存放学生（最多见的方式）
   - 优势：都这样搞，优势天然多多
   - 缺点：某些查询有些难以实现。(如：查询最近一个时间段的新加入的老师和学生并按时间排序)

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

   思路：设计3张表：人员表、老师特有属性表、学什特有属性表
   - 优势：以上两种方式的优势总和
   - 缺点：未知

解决方案

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

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

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

1. 先把全部订单的公有的属性抽象集合起来(如：订单编号、下单时间、订单状态、订单类型等)建立一张父订单表
2. 建立各类订单专有属性表(各种订单特有属性)
3. 关系：父类订单表 与 订单表 一对一的关系(每张订单表里面都能在父订单表里面有1条与之对应)

以上方式将能知足绝大多数业务状况

如上面的两种查询状况：

1. 统计各种订单中该用户未支付的订单数
2. 在列表中显示当前用户在某个时间段内全部未支付订单的信息

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

优势

• 实现业务需求能力强
• 可扩展性的特色，之后新增一种内型订单，只须要在父订单表中给订单类型新增个值，在新增长张订单特有属性表
• 业务代码将改动小或者不用改动