場景

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

影響

導致有些業(yè)務做起來會比較痛苦

比如：

統(tǒng)計當前用戶未付款訂單總數(shù)

統(tǒng)計各類訂單中該用戶未支付的訂單數(shù)

計算總數(shù)量

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

統(tǒng)計各類訂單中該用戶在這個時間段內(nèi)所有未支付的訂單信息

在業(yè)務代碼里面進行按時間排序(這里還會有各種訂單里面的相同字段信息可能會不同命名造成業(yè)務代碼里面的轉(zhuǎn)換[如：核銷訂單叫order_id，生活繳費訂單叫orderId]，將要根據(jù)訂單類型來分別判斷..............各種痛苦)

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

每新增一種內(nèi)型訂單，上面的實現(xiàn)都將隨之新增業(yè)務代碼。各種蛋疼。

思路

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

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

1.入門實現(xiàn)

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

優(yōu)點：簡單，能應對以后的各種查詢

缺點：數(shù)據(jù)冗余字段太多，查詢速度慢

2.常見的實現(xiàn)

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

優(yōu)點：都這樣搞，優(yōu)點自然多多

缺點：某些查詢有些難以實現(xiàn)。(如：查詢最近一個時間段的新加入的老師和學生并按時間排序)

3.面向?qū)ο蟮姆绞絹韺崿F(xiàn)

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

優(yōu)點：以上兩種方式的優(yōu)點總和

缺點：未知

解決方案

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

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

第三種方式使用面向?qū)ο蟮姆绞絹韺崿F(xiàn)：

先把所有訂單的公有的屬性抽象集合起來(如：訂單編號、下單時間、訂單狀態(tài)、訂單類型等)創(chuàng)建一張父訂單表

創(chuàng)建各種訂單專有屬性表(各類訂單特有屬性)

關(guān)系：父類訂單表 與 訂單表 一對一的關(guān)系(每張訂單表里面都能在父訂單表里面有1條與之對應)

以上方式將能滿足絕大多數(shù)業(yè)務情況

如上面的兩種查詢情況：

統(tǒng)計各類訂單中該用戶未支付的訂單數(shù)

在列表中顯示當前用戶在某個時間段內(nèi)所有未支付訂單的信息

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

優(yōu)點

實現(xiàn)業(yè)務需求能力強

可擴展性的特點，以后新增一種內(nèi)型訂單，只需要在父訂單表中給訂單類型新增個值，在新增加張訂單特有屬性表

業(yè)務代碼將改動小或者不用改動