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

創(chuàng)新互聯(lián)是一家專業(yè)提供三水企業(yè)網(wǎng)站建設(shè),專注與做網(wǎng)站、網(wǎng)站設(shè)計(jì)、H5建站、小程序制作等業(yè)務(wù)。10年已為三水眾多企業(yè)、政府機(jī)構(gòu)等服務(wù)。創(chuàng)新互聯(lián)專業(yè)網(wǎng)站設(shè)計(jì)公司優(yōu)惠進(jìn)行中。

正文

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

1. 問題綜述

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

忽略所有action的‘0未開始’SubState狀態(tài)。因?yàn)檫@類SubState對于BizState不會帶來變化。

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

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

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

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

核心狀態(tài)

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

• 等待買家付款

• 買家付款成功

• 賣家已發(fā)貨

• 買家已收貨

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

‘action行為’失敗的情況

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

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

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

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

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

• 等待買家付款

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

• 買家付款成功

• 賣家已發(fā)貨

• 買家已收貨

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

‘action行為’進(jìn)行中的情況

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

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

• 等待買家付款

• 付款確認(rèn)中

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

• 買家付款成功

• 賣家已發(fā)貨

• 買家已收貨

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

‘action行為’未開始的情況

忽略所有action的‘0未開始’SubState狀態(tài)。因?yàn)檫@類SubState對于BizState不會帶來變化。

‘評論comment’的處理

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

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

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

‘退貨rereturn’的處理

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

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

• 等待買家付款

• 付款確認(rèn)中

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

• 買家付款成功

• 賣家已發(fā)貨

• 買家已收貨

• 退貨中

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

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

‘退款refund’的處理

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

其他情況考慮

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

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

• 等待買家付款

• 付款確認(rèn)中

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

• 買家付款成功

• 賣家已發(fā)貨

• 買家已收貨

• 退貨中

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

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

結(jié)論

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

如果某個action屬于業(yè)務(wù)實(shí)體對應(yīng)的核心業(yè)務(wù)流程，且該action單向依賴于其前向的action，則需要將這個action產(chǎn)生的BizState放入到業(yè)務(wù)實(shí)體對應(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. 問題二、訂單表的‘訂單狀態(tài)’字段的字典值的表示形式?

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

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

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

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

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

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

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

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

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

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

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

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

綜上得出結(jié)論：

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

7. 參考資料

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

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

以上就是如何進(jìn)行數(shù)據(jù)庫“狀態(tài)”字段設(shè)計(jì)的思考與實(shí)踐，小編相信有部分知識點(diǎn)可能是我們?nèi)粘９ぷ鲿姷交蛴玫降?。希望你能通過這篇文章學(xué)到更多知識。更多詳情敬請關(guān)注創(chuàng)新互聯(lián)行業(yè)資訊頻道。