用面向对象的思维方式来设计数据库

 

场景

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

影响

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

比如：

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

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

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

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

思路

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

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

1.入门实现

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

• 优点：简单，能应对以后的各种查询
• 缺点：数据冗余字段太多，查询速度慢

2.常见的实现

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

• 优点：都这样搞，优点自然多多
• 缺点：某些查询有些难以实现。(如：查询最近一个时间段的新加入的老师和学生并按时间排序)

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

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

• 优点：以上两种方式的优点总和
• 缺点：未知

解决方案

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

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

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

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

如上面的两种查询情况：

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

优点

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

转载于:https://www.cnblogs.com/zourui4271/p/4904599.html