場景

我們有多種類型訂單：實物訂單、特享商戶訂單、核銷訂單、生活繳費訂單、電影票訂單、機票訂單、以及以后會持續新增的未知類型訂單，它們都存放在不同的訂單類型表中

影響

導致有些業務做起來會比較痛苦

比如：

• 統計當前用戶未付款訂單總數

1. 統計各類訂單中該用戶未支付的訂單數
2. 計算總數量

• 在列表中顯示當前用戶在某個時間段內所有未支付訂單的信息(實現方式如上)

1. 統計各類訂單中該用戶在這個時間段內所有未支付的訂單信息
2. 在業務代碼里面進行按時間排序(這里還會有各種訂單里面的相同字段信息可能會不同命名造成業務代碼里面的轉換[如：核銷訂單叫order_id，生活繳費訂單叫orderId]，將要根據訂單類型來分別判斷..............各種痛苦)

例外還會有個未知因素：持續新增的未知類型訂單

每新增一種內型訂單，上面的實現都將隨之新增業務代碼。各種蛋疼。

思路

上次換工作，面試遇到一道面試題，如下：

"請設計數據庫，用來存放 老師、學生等人員的信息，盡量滿足以后的擴展。(提示：請寫出3種方式，并分別寫出優缺點)"

1.入門實現

思路：設計一張表，用來存放人員信息，定義type字段，用來區分老師 和 學生

• 優點：簡單，能應對以后的各種查詢
• 缺點：數據冗余字段太多，查詢速度慢

2.常見的實現

思路：設計兩張表：一張存放老師、一張存放學生(最常見的方式)

• 優點：都這樣搞，優點自然多多
• 缺點：某些查詢有些難以實現。(如：查詢最近一個時間段的新加入的老師和學生并按時間排序)

3.面向對象的方式來實現

思路：設計3張表：人員表、老師特有屬性表、學什特有屬性表

• 優點：以上兩種方式的優點總和
• 缺點：未知

解決方案

轉回來看 我們商城的訂單表跟上面的無比相識，目前是使用第二種方式來實現，導致有些業務做起來有些不是很爽

如果換種方式按第三種方式來實現，一切又將美好起來。

第三種方式使用面向對象的方式來實現：

1. 先把所有訂單的公有的屬性抽象集合起來(如：訂單編號、下單時間、訂單狀態、訂單類型等)創建一張父訂單表
2. 創建各種訂單專有屬性表(各類訂單特有屬性)
3. 關系：父類訂單表 與 訂單表 一對一的關系(每張訂單表里面都能在父訂單表里面有1條與之對應)

以上方式將能滿足絕大多數業務情況

如上面的兩種查詢情況：

1. 統計各類訂單中該用戶未支付的訂單數
2. 在列表中顯示當前用戶在某個時間段內所有未支付訂單的信息

這里實現起來因為都能在父訂單表中獲取到，將會無比 easy，業務代碼里面的排序、字段轉換等問題也迎刃而解

優點

• 實現業務需求能力強
• 可擴展性的特點，以后新增一種內型訂單，只需要在父訂單表中給訂單類型新增個值，在新增加張訂單特有屬性表
• 業務代碼將改動小或者不用改動

博文出處：www.webdevs.cn/article/92.html