場景

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

影響

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

比如：

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

1. 統(tǒng)計各類訂單中該用戶未支付的訂單數(shù)
2. 計算總數(shù)量

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

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

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

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

思路

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

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

1.入門實現(xiàn)

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

• 優(yōu)點：簡單，能應(yīng)對以后的各種查詢
• 缺點：數(shù)據(jù)冗余字段太多，查詢速度慢

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

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

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

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

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

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

解決方案

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

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

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

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

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

如上面的兩種查詢情況：

1. 統(tǒng)計各類訂單中該用戶未支付的訂單數(shù)
2. 在列表中顯示當前用戶在某個時間段內(nèi)所有未支付訂單的信息

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

優(yōu)點

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

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