用面向對象的思路建設計數據庫

場景

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

影響

致使有些業務作起來會比較痛苦

好比：

• 統計當前用戶未付款訂單總數
  1. 統計各種訂單中該用戶未支付的訂單數
  2. 計算總數量
• 在列表中顯示當前用戶在某個時間段內全部未支付訂單的信息(實現方式如上)
  1. 統計各種訂單中該用戶在這個時間段內全部未支付的訂單信息
  2. 在業務代碼裏面進行按時間排序（這裏還會有各類訂單裏面的相同字段信息可能會不一樣命名形成業務代碼裏面的轉換[如：覈銷訂單叫order_id，生活繳費訂單叫orderId]，將要根據訂單類型來分別判斷..............各類痛苦）

例外還會有個未知因素：持續新增的未知類型訂單
每新增一種內型訂單，上面的實現都將隨之新增業務代碼。各類蛋疼。

思路

上次換工做，面試遇到一道面試題，以下：

請設計數據庫，用來存放 老師、學生等人員的信息，儘可能知足之後的擴展。（提示：請寫出3種方式，並分別寫出優缺點）

1. 入門實現

   思路：設計一張表，用來存放人員信息，定義type字段，用來區分老師 和 學生
   - 優勢：簡單，能應對之後的各類查詢
   - 缺點：數據冗餘字段太多，查詢速度慢

2. 常見的實現

   思路：設計兩張表：一張存放老師、一張存放學生（最多見的方式）
   - 優勢：都這樣搞，優勢天然多多
   - 缺點：某些查詢有些難以實現。(如：查詢最近一個時間段的新加入的老師和學生並按時間排序)

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

   思路：設計3張表：人員表、老師特有屬性表、學什特有屬性表
   - 優勢：以上兩種方式的優勢總和
   - 缺點：未知

解決方案

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

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

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

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

以上方式將能知足絕大多數業務狀況

如上面的兩種查詢狀況：

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

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

優勢

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