共計 9884 個字符，預(yù)計需要花費 25 分鐘才能閱讀完成。

本篇文章給大家分享的是有關(guān)如何進行數(shù)據(jù)庫“狀態(tài)”字段設(shè)計的思考與實踐，丸趣 TV 小編覺得挺實用的，因此分享給大家學(xué)習(xí)，希望大家閱讀完這篇文章后可以有所收獲，話不多說，跟著丸趣 TV 小編一起來看看吧。

正文

最近在做訂單及支付相關(guān)的系統(tǒng)，在訂單表的設(shè)計階段，團隊成員就“訂單狀態(tài)”數(shù)據(jù)庫字段設(shè)計有了一些分歧，網(wǎng)上也有不少關(guān)于這方面的思考和探討，結(jié)合這些資料和項目的實際情況，擬對一些共性問題進行更深一層的思考，筆耕在此，和大家一起探討。

1. 問題綜述

這里的分歧點即有團隊內(nèi)部的分歧點，也有網(wǎng)絡(luò)上常見的一些分歧點，先將存在的分歧點拋出來：

1)、訂單表的 lsquo; 訂單狀態(tài) rsquo; 字段對應(yīng)的字典值應(yīng)當(dāng)包含哪些狀態(tài)值? 對于 lsquo; 已評論 rsquo;、lsquo; 已退貨 rsquo;、rsquo; 已退款 rsquo; 這類狀態(tài)是放到 lsquo; 訂單狀態(tài) rsquo; 中? 還是獨立一個字段標(biāo)識?

2)、訂單表的 lsquo; 訂單狀態(tài) rsquo; 字段對應(yīng)的字典值如何表示? 可選項有：使用數(shù)字標(biāo)識、使用多 lsquo; 位 rsquo; 存儲方式標(biāo)識、使用具有明確業(yè)務(wù)含義的英文字符串標(biāo)識;

3)、訂單表的 lsquo; 訂單狀態(tài) rsquo; 字段使用何種類型? 可選項有：number(N)、char(N)、varchar2(N);

如果嫌分析過程過于啰嗦，可以直接拉到 *** 看結(jié)論。

2. 業(yè)務(wù)分析

我們先不去看問題，先來看看和 lsquo; 訂單(Order) rsquo; 實體相關(guān)的業(yè)務(wù)是怎樣的。下面我們會針對可能改變訂單實體狀態(tài)的行為已經(jīng)狀態(tài)變化的可能性進行詳細(xì)的分析。

訂單業(yè)務(wù)實體相關(guān)的業(yè)務(wù)流程如下：下單 (create)– 買家付款(pay)–   賣家發(fā)貨(deliver)– 買家收貨(receive)– 退貨(rereturn); 此外，還有退款(refund) 和評論(comment)，這兩個行為比較特殊，其前向行為可能存在多個。

首先，可以改變訂單業(yè)務(wù)狀態(tài)【這里的狀態(tài)不是指 lsquo; 訂單狀態(tài) rsquo;(OrderState)這個數(shù)據(jù)庫字段，而是指實際業(yè)務(wù)狀態(tài)，我們簡記為 (BizState)，以和 OrderState 區(qū)分開】的行為有哪些? 按照典型電商的業(yè)務(wù)流程，主要的行為(action) 有：下單、付款、發(fā)貨、收貨、退款 / 退貨、評論; 每一種行為的發(fā)生，都會導(dǎo)致訂單的業(yè)務(wù)狀態(tài) BizState 發(fā)生變化，比如 lsquo; 下單 rsquo; 行為會創(chuàng)建訂單，lsquo; 付款 rsquo; 行為會使訂單變?yōu)?lsquo; 已付款 rsquo;，lsquo; 發(fā)貨 rsquo; 行為可以使訂單狀態(tài)變?yōu)?lsquo; 已發(fā)貨 rsquo;，lsquo; 收貨 rsquo; 行為會使訂單狀態(tài)變?yōu)?lsquo; 已收貨 rsquo;，lsquo; 評論 rsquo; 行為會使訂單狀態(tài)變?yōu)?lsquo; 已評論 rsquo;。lsquo; 退款 / 退貨 rsquo;action 不是所有訂單都支持的，為減小復(fù)雜度，暫不考慮它們。

其次，細(xì)分下每種 action 對 BizState 帶來的影響，會發(fā)現(xiàn)還可以細(xì)分為四種子狀態(tài) (subState)：action 未開始(標(biāo)記為 0)、action 進行中(標(biāo)記為 1)、action 成功(標(biāo)記為 2)、action 失敗(標(biāo)記為 3); 理論上，將所有 action 的所有 subState 進行排列得到 4 *4*4*4*4=1024(暫未考慮 lsquo; 退貨 rsquo;); 實際上，很多組合是沒有業(yè)務(wù)意義的，是不可能存在的，比如 lsquo; 未開始已付款 … rsquo;(***20) 這一類組合是不可能發(fā)生的，應(yīng)當(dāng)舍棄。用表格將上述的組合分析如下：

通過上表，我們可以發(fā)現(xiàn)些的規(guī)律：

lsquo; 下單 rsquo;、lsquo; 付款 rsquo;、lsquo; 發(fā)貨 rsquo;、lsquo; 收貨 rsquo; 前四種 action 是存在依賴關(guān)系的，亦即后一個 action 依賴于前一個 action 的完成; 所以，他們的 SubState 組合情況就會非常少;

lsquo; 評論 comment rsquo; 這個 action 的 SubState 和其他狀態(tài)組合會有很多種可能性; 除了前面了兩行是 lsquo;X rsquo;，后面是 lsquo;? rsquo; 或者 lsquo;Y rsquo;，lsquo;? rsquo; 是指需求上是否允許在對應(yīng)的 BizState 上進行評論，如果允許，則每種 BizState 需要多出 4 種可能，這樣組合的可能性就會變得很大。

沒有業(yè)務(wù)意義的 SubState 組合被舍棄。表中的標(biāo)黑單元格，表示這個 BizState 是毫無意義的，因為 lsquo; 未下單 rsquo; 的訂單對于我們來講是不存在的，這類組合需要舍棄; 同樣的，還有很多其他的組合也是不存在的，被舍棄掉，未展示在上表中，如 lsquo; 已下單已付款未發(fā)貨已收貨 rsquo; 這種。

通常某個 action 的 SubState 為 lsquo;1 進行中 rsquo;、lsquo;3 失敗 rsquo; 時，會被忽略，但也有例外; 比如 lsquo; 付款 rsquo;action 的 lsquo;3 失敗 rsquo; 狀態(tài)，和 lsquo; 付款 rsquo;action 的 lsquo;1 進行中 rsquo; 狀態(tài)，具體分析見后面內(nèi)容。

忽略所有 action 的 lsquo;0 未開始 rsquo;SubState 狀態(tài)。因為這類 SubState 對于 BizState 不會帶來變化。

綜合下來，我們得到上表的 BizState，注意這里的 Comment  action 未進行細(xì)化處理，如果細(xì)化處理，會發(fā)現(xiàn) BizState 的可能性會增大很多很多。

接下來我們就之前提出的這些問題進行逐個討論。

3. 問題一、訂單表的 lsquo; 訂單狀態(tài) rsquo; 字段應(yīng)當(dāng)包含哪些狀態(tài)值?

什么樣的 lsquo; 訂單業(yè)務(wù)狀態(tài) rsquo;(BizState)需要記錄到系統(tǒng)層面的 lsquo; 訂單狀態(tài) rsquo;(OrderState)字段呢? 如果記錄多了，則系統(tǒng)處理的復(fù)雜度會增大; 記錄少了，那么 lsquo; 訂單狀態(tài) rsquo;(OrderState)字段就不能完整的表示出訂單實體狀態(tài)變化情況。

核心狀態(tài)

通過上面的業(yè)務(wù)分析可知：大部分存在依賴關(guān)系的 action(create、pay、deliver、receive)，他們產(chǎn)生的合理的 SubState 組合是非常少的，而且他們之間的依賴是單向依賴，狀態(tài)機的處理也很簡單，因此，我們先將這部分 BizState 納入到 OrderState 中：

等待買家付款

買家付款成功

賣家已發(fā)貨

買家已收貨

目前的訂單狀態(tài)流轉(zhuǎn)：

lsquo;action 行為 rsquo; 失敗的情況

對于 action 的 SubState 是 lsquo;3 失敗 rsquo; 的處理，需要針對不同的 action 進行分析。類似 lsquo; 下單 Create rsquo; 這樣的 action，如果失敗，則可以直接將 OrderState 置為 lsquo; 訂單創(chuàng)建失敗 rsquo;，因為 Create  action 是 *** 個 action，它的失敗意味著 Order 實體出生即死，BizState 置為終態(tài)，對于這個 BizState 應(yīng)當(dāng)納入到 OrderState 中記錄，不過這個 OrderState 其實對于用戶并無多大用處，因為用戶并不會關(guān)心下單失敗的訂單，他更關(guān)心的是重新下單;

對于 lsquo; 支付 rsquo; 失敗，則要看需求，如果需求要求用戶可以繼續(xù)支付，則訂單需要保留，并且狀態(tài)仍然為 lsquo; 等待買家付款 rsquo;，如果不允許再支付，則理論上可以將 BizState 置為 lsquo; 支付失敗 rsquo; 終態(tài)，所以，lsquo; 支付失敗 rsquo; 的 BizState 終態(tài)也應(yīng)當(dāng)記錄到 OrderState 字段中。

對于 lsquo; 發(fā)貨 rsquo; 失敗、lsquo; 收貨 rsquo; 失敗的情況，通常是不會發(fā)生的，即使發(fā)生也不屬于系統(tǒng)能夠控制的范疇，系統(tǒng)記錄并無意義，更具建設(shè)性的做法是通過線下手段盡快解決問題，重新發(fā)貨等等，所以對于這些狀態(tài)系統(tǒng)的 OrderState 字段不予記錄。

這樣下來我們的 OrderState 字典值增加到 6 個，加粗項為新增：

創(chuàng)建訂單失敗(終態(tài))

等待買家付款

買家付款失敗(終態(tài)，依賴需求而定)

買家付款成功

賣家已發(fā)貨

買家已收貨

目前的訂單狀態(tài)流轉(zhuǎn)：

lsquo;action 行為 rsquo; 進行中的情況

對于 action 的 SubState 是 lsquo;1 進行中 rsquo; 的處理，同樣需要具體場景具體分析。lsquo; 付款 rsquo; 行為是用戶發(fā)起的，但是并不是和訂單系統(tǒng)之間的交互，涉及到支付系統(tǒng)的處理，這個領(lǐng)域也不是訂單系統(tǒng)可控的，但關(guān)系到錢，用戶比較關(guān)系，所以對于這樣一個中間態(tài)，我們需要記錄，以便用戶通過訂單系統(tǒng)查詢訂單狀態(tài)，為便于用戶理解，將此狀態(tài)在 OrderState 中記為 lsquo; 付款確認(rèn)中 rsquo;; lsquo; 發(fā)貨 rsquo; lsquo; 收貨 rsquo; 進行中的情況，不是訂單系統(tǒng)可以控制的領(lǐng)域，我們可以把他們當(dāng)著行為 lsquo; 未開始 rsquo; 處理，比如 lsquo; 發(fā)貨進行中 rsquo;，訂單系統(tǒng)的 OrderState 值為 lsquo; 買家已付款 rsquo;，但給用戶看到的提示信息是 lsquo; 買家已付款，等待賣家發(fā)貨 rsquo;，實際上這時候賣家可能正在發(fā)貨中，但是用戶不會去關(guān)心到底有沒有打包好貨物什么的，所以這類 lsquo; 進行中 rsquo; 狀態(tài)可以舍棄。這樣下來訂單系統(tǒng)的 OrderState 字段又多了一個字典值：lsquo; 付款確認(rèn)中 rsquo;：

創(chuàng)建訂單失敗(終態(tài))

等待買家付款

付款確認(rèn)中

買家付款失敗(終態(tài)，依賴需求而定)

買家付款成功

賣家已發(fā)貨

買家已收貨

目前的訂單狀態(tài)流轉(zhuǎn)：

lsquo;action 行為 rsquo; 未開始的情況

忽略所有 action 的 lsquo;0 未開始 rsquo;SubState 狀態(tài)。因為這類 SubState 對于 BizState 不會帶來變化。

lsquo; 評論 comment rsquo; 的處理

***，再來看看 lsquo; 評論 comment rsquo; 這個 action。如果需求上要求：只有買家收貨后才能發(fā)起 lsquo; 評論 rsquo; 操作，則可以任務(wù) lsquo; 評論 comment rsquo; 單向依賴于 lsquo;receive 收貨 rsquo; 行為，那么可以將這個 action 的 subState 對應(yīng)的少量 BizState(應(yīng)當(dāng)只有 lsquo; 買家已評論 rsquo;、lsquo; 賣家已評論 rsquo; 狀態(tài))納入 OrderState 字段統(tǒng)一記錄; 但是如果需求是：買家在下單后就可以開始評論，比如如果賣家發(fā)貨慢了，買家可以上去吐槽，那么 lsquo; 評論 comment rsquo; 就不是單向依賴于 lsquo;receive 收貨 rsquo; 行為了，而是多向依賴于 lsquo;pay 付款 rsquo;、lsquo;deliver 發(fā)貨 rsquo;、lsquo;receive 收貨 rsquo;，那么這些 actions 的 subState 組合可能性就暴增，BizState 的字典取值也會暴增，顯然，不應(yīng)當(dāng)將這么多的 BizState 交給 OrderState 來記錄，而應(yīng)當(dāng)由一個獨立的數(shù)據(jù)庫字段負(fù)責(zé)記錄 lsquo; 評論 comment rsquo; 的 SubState，我們可以將這個字段取名

為 lsquo;CommentState rsquo;(評論狀態(tài))，它的字典值不多，只有：lsquo; 未評論 rsquo;、lsquo; 買家已評論 rsquo;、lsquo; 賣家已評論 rsquo;; 其實，對于前一種需求，也可以不講 lsquo; 評論 comment rsquo; 對應(yīng)的 SubState 產(chǎn)生的 BizState 納入 OrderState，因為用戶對于評論與否其實并不是那么關(guān)心的，也就是說 lsquo; 評論 comment rsquo; 并不是核心業(yè)務(wù)流程，為了降低核心業(yè)務(wù)流程的系統(tǒng)處理復(fù)雜度，將其從核心業(yè)務(wù)流程中剝離出來較好。

綜上，我們應(yīng)當(dāng)將 lsquo; 評論 comment rsquo; 對應(yīng)的 BizState 獨立到一個字段中記錄。

lsquo; 退貨 rereturn rsquo; 的處理

再來看看 lsquo; 退貨 rereturn rsquo; 行為對應(yīng)的 BizState 的處理。lsquo; 退貨 rereturn rsquo; 并不是所有訂單都會經(jīng)歷的，但是一旦涉及，則 lsquo; 退貨 rereturn rsquo; 在業(yè)務(wù)流程上必定是單向依賴于單向依賴于 lsquo;receive 收貨 rsquo;，所以應(yīng)當(dāng)將 lsquo; 退貨 rereturn rsquo; 產(chǎn)生的 BizState(lsquo; 退貨中 rsquo;、lsquo; 退貨成功 rsquo;，lsquo; 退款失敗 rsquo; 和 lsquo; 未退貨 rsquo; 被忽略，見上面解釋)納入 OrderState 一并記錄; 這樣我們的 OrderState 有多了兩種字典值，這里我們不考慮一個訂單中有多種商品的情況，故把 lsquo; 退貨成功 當(dāng)著終態(tài)處理，如果是一個訂單多種貨物的情況，需要重新仔細(xì)分析。加粗項為新增：

創(chuàng)建訂單失敗(終態(tài))

等待買家付款

付款確認(rèn)中

買家付款失敗(終態(tài)，依賴需求而定)

買家付款成功

賣家已發(fā)貨

買家已收貨

退貨中

退貨成功(終態(tài))

目前的訂單狀態(tài)流轉(zhuǎn)：

lsquo; 退款 refund rsquo; 的處理

*** 來看下 lsquo; 退款 refund rsquo; 行為對應(yīng)的 BizState 的處理。首先，我們需要知道 lsquo; 退貨 rsquo; 和 lsquo; 退款 rsquo; 是兩種不同的業(yè)務(wù)行為，他們的關(guān)系是：通常意義上，lsquo; 退貨 rsquo; 必然導(dǎo)致 lsquo; 退款 rsquo;，但是 lsquo; 退款 rsquo; 可以沒有 lsquo; 退貨 rsquo; 的參與(這里不討論特殊情況，比如對于虛擬貨物來講，付款成功通常以為著收貨成功，這時候就只能是在由 lsquo; 退貨 rsquo; 導(dǎo)致 lsquo; 退款 rsquo;)，比如電商允許用戶付款成功后收到貨物前發(fā)起 lsquo; 退款 rsquo;。也就是說 lsquo; 退款 refund rsquo; 并不單向依賴于 lsquo; 退貨 rereturn rsquo;，和 lsquo; 評論 comment rsquo; 一樣是多項依賴，所以，我們可以參考 lsquo; 評論 comment rsquo; 的處理方式，單獨建立一個字段 lsquo;RefundState 退款狀態(tài) rsquo; 記錄 lsquo; 退款 refund rsquo; 產(chǎn)生的 BizState，這個狀態(tài)字段的字典值有：退款中，退款成功。

其他情況考慮

另外，可能還有一些增強型需求，讓客戶體驗更好，比如用戶可以創(chuàng)建訂單之后付款之前，將訂單取消，或者由系統(tǒng)跑批將用戶長時間未支付的訂單關(guān)閉，這會產(chǎn)生一種新的 action mdash; mdash; lsquo;close 關(guān)閉 rsquo;，對應(yīng)的會產(chǎn)生一種新的有意義的 BizState mdash; mdash; lsquo; 訂單關(guān)閉 / 取消 rsquo;，這個不屬于核心流程中的，且并無糾結(jié)之處，不予詳細(xì)討論，羅列如下：

創(chuàng)建訂單失敗(終態(tài))

等待買家付款

付款確認(rèn)中

買家付款失敗(終態(tài)，依賴需求而定)

買家付款成功

賣家已發(fā)貨

買家已收貨

退貨中

退貨成功(終態(tài))

訂單關(guān)閉(終態(tài))

結(jié)論

綜上，我們可以得出放入數(shù)據(jù)庫 rsquo; 訂單狀態(tài) lsquo; 字段的標(biāo)準(zhǔn)：核心業(yè)務(wù)流程，向前單向依賴。擴展到其他業(yè)務(wù)實體是一樣的，這里說的 rsquo; 訂單狀態(tài) lsquo; 字段實際是指該業(yè)務(wù)實體對應(yīng)的數(shù)據(jù)表的主業(yè)務(wù)狀態(tài)字段。我們把結(jié)論擴展一下：

如果某個 action 屬于業(yè)務(wù)實體對應(yīng)的核心業(yè)務(wù)流程，且該 action 單向依賴于其前向的 action，則需要將這個 action 產(chǎn)生的 BizState 放入到業(yè)務(wù)實體對應(yīng)的數(shù)據(jù)庫表的主狀態(tài)字段中記錄。

OrderState 字段記錄的 BizState 業(yè)務(wù)狀態(tài)有 10 種，其中 4 種是終態(tài)，其余狀態(tài)為中間態(tài)。這些狀態(tài)的流轉(zhuǎn)關(guān)系為：

4. 問題二、訂單表的 lsquo; 訂單狀態(tài) rsquo; 字段的字典值的表示形式?

先列出可選項：使用數(shù)字標(biāo)識、使用多 lsquo; 位 rsquo; 存儲方式標(biāo)識、使用具有明確業(yè)務(wù)含義的英文字符串標(biāo)識; 對可選項做逐一解釋：

a、使用數(shù)字標(biāo)識 mdash; mdash; 使用一個數(shù)字標(biāo)識一種狀態(tài)，并未要求是 sequence 的; 如 lsquo; 等待買家付款 rsquo; 表示為 lsquo;0 rsquo;;

b、使用多 lsquo; 位 rsquo; 存儲方式標(biāo)識 mdash; mdash; 將某種行為是否發(fā)生對應(yīng)的狀態(tài)對應(yīng)到一個位上，比如 lsquo; 是否付款 rsquo; 定義在 *** 位，lsquo; 是否發(fā)貨 rsquo; 定義在第二位，lsquo; 是否收貨 rsquo; 定義在第三位，lsquo; 是否評論 rsquo; 定義在第四位，則狀態(tài) lsquo; 賣家已收貨未評論 rsquo; 可以表示為：0111; 而 lsquo; 等待買家付款 rsquo; 則表示為 lsquo;0000 rsquo;; 當(dāng)然這里的 lsquo; 位 rsquo; 可能是二進制的也可能是 N 進制，后面我們詳細(xì)討論。

c、使用具有明確業(yè)務(wù)含義的英文字符串標(biāo)識 mdash; mdash; 該方案和方案 a 類似，不過字典值變?yōu)榫哂忻鞔_業(yè)務(wù)含義的英文支付串，如 lsquo; 等待買家付款 rsquo; 表示為 lsquo;WAIT_BUYER_PAY rsquo;;

方案 a 是數(shù)據(jù)庫字段字典的慣用方式，簡單直觀，但是有一個壞處在于：當(dāng)字典值較多時，數(shù)據(jù)庫表的使用者記不住字典的含義，需要反復(fù)查找資料確認(rèn); 有人會說將字典值寫到字段的注釋里，這個在實踐中不是很靠譜，通常表建立后，如果字段增加了字典值，通常開發(fā)人員都會忽略更改字典值; 而且在使用工具 (如 pl/sql) 查詢數(shù)據(jù)庫時，并不會將所有字典值展示出來;

通過問題一的分析，可知：方案 b 使用多 lsquo; 位 rsquo; 存儲方式會增加復(fù)雜度，并沒有必要，可以通過將 lsquo; 是否評論 rsquo; 狀態(tài)獨立成一個字段進行表示。

方案 c 和方案 a 類似，好處在于通過字典值直接知道業(yè)務(wù)含義，壞處在于會給編碼和手工查詢時帶來復(fù)雜度，通常人們也記不住 lsquo; 等待買家付款 rsquo; 的英文字典

是 lsquo;WAIT_BUYER_PAY rsquo;，那么手動寫 sql 查詢 lsquo; 等待買家付款 rsquo; 時就犯迷糊了。

折中之后，我們組合方案 a 和方案 c，得到方案 d：另外建立一張字典表，存儲：數(shù)字形式的字典值、字典英文名稱、字典中文簡稱、字典解釋; 訂單實體表的 OrderState 字段使用數(shù)字作為字典值。

對于方案 d，看到 OrderState 的數(shù)字形式狀態(tài)時，可以先看看字段注釋是否有此字典的定義，如果沒有就取查下字典表，得到字典值和含義; 在編碼和手動 sql 查詢時也會變得比較容易，數(shù)字的位數(shù)畢竟要少些; 建立字典表的其他好處還有：字典的解釋可以寫的很詳細(xì)，在報表中要求展示字典中文名時，也能直接從數(shù)據(jù)庫聯(lián)表查詢得到，而不必額外做一次映射。(有參考：數(shù)據(jù)庫表設(shè)計(狀態(tài)字段))

那么對于字典數(shù)量很少的狀態(tài)字段是否有必要額外新建一張字典表呢? 這個根據(jù)實際情況考慮，通常可以先不建，如果后續(xù)有業(yè)務(wù)場景需要再行創(chuàng)建也不遲。

而對于非業(yè)務(wù)實體表的系統(tǒng)日志 / 跑批記錄表等的狀態(tài)，則完全可以使用數(shù)字形式的字典，因為通常不會有業(yè)務(wù)場景使用到這些字典值，而且這些字典值域應(yīng)當(dāng)會比較小，所以沒有必要為他們創(chuàng)建單獨的字典表。

綜上得出結(jié)論：

1)、字典值域較多、變化較多、報表等業(yè)務(wù)場景會使用到的業(yè)務(wù)實體表的業(yè)務(wù)狀態(tài)字段，使用 lsquo; 方案 d：新建字典表 rsquo; 的方案處理; 如 lsquo; 訂單業(yè)務(wù)實體表 rsquo; 中的 lsquo; 訂單狀態(tài) rsquo; 字段。

2)、字典值域較少、變化較少、報表等業(yè)務(wù)場景不會使用到的業(yè)務(wù)實體表的業(yè)務(wù)狀態(tài)字段，使用 lsquo; 方案 a：使用數(shù)字標(biāo)識字典 rsquo; 的方案處理; 如 lsquo; 支付寶的支付流水表 rsquo; 的 lsquo; 支付流水狀態(tài) rsquo; 字段。

3)、系統(tǒng)日志 / 跑批記錄表的狀態(tài)字段，使用 lsquo; 方案 a：使用數(shù)字標(biāo)識字典 rsquo; 的方案處理; 如 lsquo; 待收貨記錄表 rsquo; 的 lsquo; 跑批狀態(tài) rsquo; 字段。

5. 問題三、數(shù)據(jù)庫表的 lsquo; 狀態(tài) rsquo; 字段使用何種類型

列出可選項：number(N)、char(N)、varchar2(N)，其中 N 是一個長度值。

這個問題主要需要考慮使用場景、擴展性、性能、存儲。

lsquo; 狀態(tài) rsquo; 字段主要使用在查詢場景，且通常是 lsquo;= rsquo; 或者 lsquo;in rsquo; 的查詢，并沒有區(qū)間類的查詢，故三者差別不大;

對于性能，參考 [原創(chuàng)] 在 Oracle 10g，Number、Char 和 Varchar2 類型作為主鍵，查詢效率分析  char(N)、varchar2(N)性能優(yōu)于 number(N)，故舍棄 number(N)。

考慮到擴展性，char(N)、varchar2(N)差不多;

考慮到存儲，varchar2 更加占用空間更小，故選擇 varchar2(N)。

綜上：選擇 varchar2(N)作為數(shù)據(jù)庫 lsquo; 狀態(tài) rsquo; 字段的類型。

6. 問題結(jié)論匯總

1)、訂單表的 lsquo; 訂單狀態(tài) rsquo; 字段對應(yīng)的字典值應(yīng)當(dāng)包含哪些狀態(tài)值? 對于 lsquo; 已評論 rsquo;、lsquo; 已退貨 rsquo; 這類狀態(tài)是放到 lsquo; 訂單狀態(tài) rsquo; 中? 還是獨立一個字段標(biāo)識?

如果某個 action(行為，如支付)屬于業(yè)務(wù)實體對應(yīng)的核心業(yè)務(wù)流程，且該 action 單向依賴于其前向的 action，則需要將這個 action 產(chǎn)生的業(yè)務(wù)狀態(tài)放入到業(yè)務(wù)實體對應(yīng)的數(shù)據(jù)庫表的主狀態(tài)字段中記錄。

問題中的 lsquo; 已評論 rsquo; 由 lsquo; 評論 rsquo; 行為產(chǎn)生，而 lsquo; 評論 rsquo; 這個 action 并不是訂單業(yè)務(wù)實體的核心業(yè)務(wù)流程，且可能存在多個前向依賴 action(支付、發(fā)貨、收貨等)，所以應(yīng)當(dāng)獨立到一個字段標(biāo)識。

問題中的 lsquo; 已退貨 rsquo; 由 lsquo; 退貨 rsquo; 行為產(chǎn)生，而 lsquo; 退貨 rsquo; 這個 action 是訂單業(yè)務(wù)實體的核心業(yè)務(wù)流程，用戶非常關(guān)心，且只單向依賴于 lsquo; 收貨 rsquo;action，所以應(yīng)當(dāng)記錄到訂單業(yè)務(wù)實體表的 lsquo; 訂單狀態(tài) rsquo; 字段中。

問題中的 lsquo; 已退款 rsquo; 由 lsquo; 退款 rsquo; 行為產(chǎn)生，而 lsquo; 退款 rsquo; 這個 action 是訂單業(yè)務(wù)實體的核心業(yè)務(wù)流程，用戶非常關(guān)心，但是這個 action 存在多個前向依賴 action(支付、發(fā)貨、收貨等)，所以應(yīng)當(dāng)獨立到一個字段標(biāo)識。

2)、訂單表的 lsquo; 訂單狀態(tài) rsquo; 字段對應(yīng)的字典值如何表示? 可選項有：使用數(shù)字標(biāo)識、使用多 lsquo; 位 rsquo; 存儲方式標(biāo)識、使用具有明確業(yè)務(wù)含義的英文字符串標(biāo)識;

i、字典值域較多、變化較多、報表等業(yè)務(wù)場景會使用到的業(yè)務(wù)實體表的業(yè)務(wù)狀態(tài)字段，使用 lsquo; 方案 d：新建字典表 rsquo; 的方案處理; 如 lsquo; 訂單業(yè)務(wù)實體表 rsquo; 中的 lsquo; 訂單狀態(tài) rsquo; 字段。

j、字典值域較少、變化較少、報表等業(yè)務(wù)場景不會使用到的業(yè)務(wù)實體表的業(yè)務(wù)狀態(tài)字段，使用 lsquo; 方案 a：使用數(shù)字標(biāo)識字典 rsquo; 的方案處理; 如 lsquo; 支付寶的支付流水表 rsquo; 的 lsquo; 支付流水狀態(tài) rsquo; 字段。

k、系統(tǒng)日志 / 跑批記錄表的狀態(tài)字段，使用 lsquo; 方案 a：使用數(shù)字標(biāo)識字典 rsquo; 的方案處理; 如 lsquo; 待收貨記錄表 rsquo; 的 lsquo; 跑批狀態(tài) rsquo; 字段。

3)、訂單表的 lsquo; 訂單狀態(tài) rsquo; 字段使用何種類型? 可選項有：number(N)、char(N)、varchar2(N);

varchar2(N)占用存儲更少，且具有同等的性能、擴展性，選擇 varchar2(N)作為數(shù)據(jù)庫 lsquo; 狀態(tài) rsquo; 字段的類型。

7. 參考資料

數(shù)據(jù)庫表設(shè)計(狀態(tài)字段)

[原創(chuàng)]在 Oracle 10g，Number、Char 和 Varchar2 類型作為主鍵，查詢效率分析

以上就是如何進行數(shù)據(jù)庫“狀態(tài)”字段設(shè)計的思考與實踐，丸趣 TV 小編相信有部分知識點可能是我們?nèi)粘９ぷ鲿姷交蛴玫降摹ＯＭ隳芡ㄟ^這篇文章學(xué)到更多知識。更多詳情敬請關(guān)注丸趣 TV 行業(yè)資訊頻道。