最近在做訂單及支付相關(guān)的系統(tǒng)炮障，在訂單表的設(shè)計(jì)階段宵距，團(tuán)隊(duì)成員就‘訂單狀態(tài)’數(shù)據(jù)庫(kù)字段設(shè)計(jì)有了一些分歧憾股，網(wǎng)上也有不少關(guān)于這方面的思考和探討，結(jié)合這些資料和項(xiàng)目的實(shí)際情況延届，擬對(duì)一些共性問(wèn)題進(jìn)行更深一層的思考剪勿，筆耕在此，和大家一起探討方庭。
問(wèn)題綜述
這里的分歧點(diǎn)即有團(tuán)隊(duì)內(nèi)部的分歧點(diǎn)厕吉，也有網(wǎng)絡(luò)上常見(jiàn)的一些分歧點(diǎn)，先將存在的分歧點(diǎn)拋出來(lái)：
1械念、訂單表的‘訂單狀態(tài)’字段對(duì)應(yīng)的字典值應(yīng)當(dāng)包含哪些狀態(tài)值头朱？對(duì)于‘已評(píng)論’、‘已退貨’龄减、’已退款’這類(lèi)狀態(tài)是放到‘訂單狀態(tài)’中项钮？還是獨(dú)立一個(gè)字段標(biāo)識(shí)？
2、訂單表的‘訂單狀態(tài)’字段對(duì)應(yīng)的字典值如何表示烁巫？可選項(xiàng)有：使用數(shù)字標(biāo)識(shí)署隘、使用多‘位’存儲(chǔ)方式標(biāo)識(shí)、使用具有明確業(yè)務(wù)含義的英文字符串標(biāo)識(shí)亚隙；
3磁餐、訂單表的‘訂單狀態(tài)’字段使用何種類(lèi)型？可選項(xiàng)有：number(N)阿弃、char(N)诊霹、varchar2(N);
如果嫌分析過(guò)程過(guò)于啰嗦，可以直接拉到最后看結(jié)論渣淳。
業(yè)務(wù)分析
我們先不去看問(wèn)題脾还，先來(lái)看看和‘訂單（Order）’實(shí)體相關(guān)的業(yè)務(wù)是怎樣的。下面我們會(huì)針對(duì)可能改變訂單實(shí)體狀態(tài)的行為已經(jīng)狀態(tài)變化的可能性進(jìn)行詳細(xì)的分析入愧。
訂單業(yè)務(wù)實(shí)體相關(guān)的業(yè)務(wù)流程如下：下單（create）--> 買(mǎi)家付款（pay）--> 賣(mài)家發(fā)貨（deliver）-->買(mǎi)家收貨（receive）-->退貨（rereturn）鄙漏；此外，還有退款（refund）和評(píng)論（comment）砂客，這兩個(gè)行為比較特殊泥张，其前向行為可能存在多個(gè)呵恢。
首先鞠值，可以改變訂單業(yè)務(wù)狀態(tài)【這里的狀態(tài)不是指‘訂單狀態(tài)’（OrderState）這個(gè)數(shù)據(jù)庫(kù)字段，而是指實(shí)際業(yè)務(wù)狀態(tài)渗钉，我們簡(jiǎn)記為（BizState）彤恶，以和OrderState區(qū)分開(kāi)】的行為有哪些？按照典型電商的業(yè)務(wù)流程鳄橘，主要的行為（action）有：下單声离、付款、發(fā)貨瘫怜、收貨术徊、退款/退貨、評(píng)論鲸湃；每一種行為的發(fā)生赠涮，都會(huì)導(dǎo)致訂單的業(yè)務(wù)狀態(tài)BizState發(fā)生變化，比如‘下單’行為會(huì)創(chuàng)建訂單暗挑，‘付款’行為會(huì)使訂單變?yōu)椤迅犊睢癯l(fā)貨’行為可以使訂單狀態(tài)變?yōu)椤寻l(fā)貨’，‘收貨’行為會(huì)使訂單狀態(tài)變?yōu)椤咽肇洝桑u(píng)論’行為會(huì)使訂單狀態(tài)變?yōu)椤言u(píng)論’垃它。‘退款/退貨’action不是所有訂單都支持的，為減小復(fù)雜度国拇，暫不考慮它們洛史。
其次，細(xì)分下每種action對(duì)BizState帶來(lái)的影響酱吝，會(huì)發(fā)現(xiàn)還可以細(xì)分為四種子狀態(tài)（subState）：action未開(kāi)始（標(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í)際上，很多組合是沒(méi)有業(yè)務(wù)意義的该镣，是不可能存在的冻璃，比如‘未開(kāi)始已付款...’（***20）這一類(lèi)組合是不可能發(fā)生的，應(yīng)當(dāng)舍棄损合。用表格將上述的組合分析如下：
通過(guò)上表，我們可以發(fā)現(xiàn)些的規(guī)律：
‘下單’嫁审、‘付款’跋炕、‘發(fā)貨’、‘收貨’前四種action是存在依賴(lài)關(guān)系的律适，亦即后一個(gè)action依賴(lài)于前一個(gè)action的完成辐烂；所以，他們的SubState組合情況就會(huì)非常少捂贿；
‘評(píng)論comment’這個(gè)action的SubState和其他狀態(tài)組合會(huì)有很多種可能性纠修；除了前面了兩行是‘X’，后面是‘?’或者‘Y’厂僧，‘扣草？’是指需求上是否允許在對(duì)應(yīng)的BizState上進(jìn)行評(píng)論，如果允許颜屠，則每種BizState需要多出4種可能辰妙，這樣組合的可能性就會(huì)變得很大。
沒(méi)有業(yè)務(wù)意義的SubState組合被舍棄汽纤。表中的標(biāo)黑單元格上岗，表示這個(gè)BizState是毫無(wú)意義的，因?yàn)椤聪聠巍挠唵螌?duì)于我們來(lái)講是不存在的蕴坪，這類(lèi)組合需要舍棄肴掷；同樣的敬锐，還有很多其他的組合也是不存在的，被舍棄掉呆瞻，未展示在上表中台夺，如‘已下單已付款未發(fā)貨已收貨’這種。
通常某個(gè)action的SubState為‘1進(jìn)行中’痴脾、‘3失敗’時(shí)颤介，會(huì)被忽略，但也有例外赞赖；比如‘付款’action的‘3失敗’狀態(tài)滚朵，和‘付款’action的‘1進(jìn)行中’狀態(tài)，具體分析見(jiàn)后面內(nèi)容前域。
忽略所有action的‘0未開(kāi)始’SubState狀態(tài)辕近。因?yàn)檫@類(lèi)SubState對(duì)于BizState不會(huì)帶來(lái)變化。
綜合下來(lái)匿垄，我們得到上表的BizState移宅，注意這里的Comment action未進(jìn)行細(xì)化處理，如果細(xì)化處理椿疗，會(huì)發(fā)現(xiàn)BizState的可能性會(huì)增大很多很多漏峰。
接下來(lái)我們就之前提出的這些問(wèn)題進(jìn)行逐個(gè)討論。
問(wèn)題一届榄、訂單表的‘訂單狀態(tài)’字段應(yīng)當(dāng)包含哪些狀態(tài)值浅乔？
什么樣的‘訂單業(yè)務(wù)狀態(tài)’（BizState）需要記錄到系統(tǒng)層面的‘訂單狀態(tài)’（OrderState）字段呢？如果記錄多了痒蓬，則系統(tǒng)處理的復(fù)雜度會(huì)增大童擎；記錄少了，那么‘訂單狀態(tài)’（OrderState）字段就不能完整的表示出訂單實(shí)體狀態(tài)變化情況攻晒。
核心狀態(tài)
通過(guò)上面的業(yè)務(wù)分析可知：大部分存在依賴(lài)關(guān)系的action（create、pay班挖、deliver鲁捏、receive），他們產(chǎn)生的合理的SubState組合是非常少的萧芙，而且他們之間的依賴(lài)是單向依賴(lài)给梅，狀態(tài)機(jī)的處理也很簡(jiǎn)單，因此双揪，我們先將這部分BizState納入到OrderState中：
等待買(mǎi)家付款
買(mǎi)家付款成功
賣(mài)家已發(fā)貨
買(mǎi)家已收貨
目前的訂單狀態(tài)流轉(zhuǎn)：
‘a(chǎn)ction行為’失敗的情況
對(duì)于action的SubState是‘3失敗’的處理动羽，需要針對(duì)不同的action進(jìn)行分析。類(lèi)似‘下單Create’這樣的action渔期，如果失敗运吓，則可以直接將OrderState置為‘訂單創(chuàng)建失敗’渴邦，因?yàn)镃reate action是第一個(gè)action，它的失敗意味著Order實(shí)體出生即死拘哨，BizState置為終態(tài)谋梭，對(duì)于這個(gè)BizState應(yīng)當(dāng)納入到OrderState中記錄，不過(guò)這個(gè)OrderState其實(shí)對(duì)于用戶(hù)并無(wú)多大用處倦青，因?yàn)橛脩?hù)并不會(huì)關(guān)心下單失敗的訂單瓮床，他更關(guān)心的是重新下單；
對(duì)于‘支付’失敗产镐，則要看需求隘庄，如果需求要求用戶(hù)可以繼續(xù)支付，則訂單需要保留癣亚，并且狀態(tài)仍然為‘等待買(mǎi)家付款’峭沦，如果不允許再支付，則理論上可以將BizState置為‘支付失敗’終態(tài)逃糟，所以吼鱼，‘支付失敗’的BizState終態(tài)也應(yīng)當(dāng)記錄到OrderState字段中。
對(duì)于‘發(fā)貨’失敗绰咽、‘收貨’失敗的情況菇肃，通常是不會(huì)發(fā)生的，即使發(fā)生也不屬于系統(tǒng)能夠控制的范疇取募，系統(tǒng)記錄并無(wú)意義琐谤，更具建設(shè)性的做法是通過(guò)線(xiàn)下手段盡快解決問(wèn)題，重新發(fā)貨等等玩敏，所以對(duì)于這些狀態(tài)系統(tǒng)的OrderState字段不予記錄斗忌。
這樣下來(lái)我們的OrderState字典值增加到6個(gè)，加粗項(xiàng)為新增：
創(chuàng)建訂單失斖邸（終態(tài)）
等待買(mǎi)家付款
買(mǎi)家付款失斨簟（終態(tài)，依賴(lài)需求而定）
買(mǎi)家付款成功
賣(mài)家已發(fā)貨
買(mǎi)家已收貨
目前的訂單狀態(tài)流轉(zhuǎn)：
‘a(chǎn)ction行為’進(jìn)行中的情況
對(duì)于action的SubState是‘1進(jìn)行中’的處理砰粹，同樣需要具體場(chǎng)景具體分析唧躲。‘付款’行為是用戶(hù)發(fā)起的碱璃，但是并不是和訂單系統(tǒng)之間的交互弄痹，涉及到支付系統(tǒng)的處理，這個(gè)領(lǐng)域也不是訂單系統(tǒng)可控的嵌器，但關(guān)系到錢(qián)肛真，用戶(hù)比較關(guān)系，所以對(duì)于這樣一個(gè)中間態(tài)爽航，我們需要記錄蚓让，以便用戶(hù)通過(guò)訂單系統(tǒng)查詢(xún)訂單狀態(tài)乾忱，為便于用戶(hù)理解，將此狀態(tài)在OrderState中記為‘付款確認(rèn)中’凭疮；‘發(fā)貨’‘收貨’進(jìn)行中的情況饭耳，不是訂單系統(tǒng)可以控制的領(lǐng)域，我們可以把他們當(dāng)著行為‘未開(kāi)始’處理执解，比如‘發(fā)貨進(jìn)行中’寞肖，訂單系統(tǒng)的OrderState值為‘買(mǎi)家已付款’，但給用戶(hù)看到的提示信息是‘買(mǎi)家已付款衰腌，等待賣(mài)家發(fā)貨’新蟆，實(shí)際上這時(shí)候賣(mài)家可能正在發(fā)貨中，但是用戶(hù)不會(huì)去關(guān)心到底有沒(méi)有打包好貨物什么的右蕊，所以這類(lèi)‘進(jìn)行中’狀態(tài)可以舍棄琼稻。這樣下來(lái)訂單系統(tǒng)的OrderState字段又多了一個(gè)字典值：‘付款確認(rèn)中’：
創(chuàng)建訂單失敗（終態(tài)）
等待買(mǎi)家付款
付款確認(rèn)中
買(mǎi)家付款失斎那簟（終態(tài)帕翻，依賴(lài)需求而定）
買(mǎi)家付款成功
賣(mài)家已發(fā)貨
買(mǎi)家已收貨
目前的訂單狀態(tài)流轉(zhuǎn)：
‘a(chǎn)ction行為’未開(kāi)始的情況
忽略所有action的‘0未開(kāi)始’SubState狀態(tài)。因?yàn)檫@類(lèi)SubState對(duì)于BizState不會(huì)帶來(lái)變化萝风。
‘評(píng)論comment’的處理
最后嘀掸，再來(lái)看看‘評(píng)論comment’這個(gè)action。如果需求上要求：只有買(mǎi)家收貨后才能發(fā)起‘評(píng)論’操作规惰，則可以任務(wù)‘評(píng)論comment’單向依賴(lài)于‘receive收貨’行為睬塌，那么可以將這個(gè)action的subState對(duì)應(yīng)的少量BizState（應(yīng)當(dāng)只有‘買(mǎi)家已評(píng)論’、‘賣(mài)家已評(píng)論’狀態(tài)）納入OrderState字段統(tǒng)一記錄歇万；但是如果需求是：買(mǎi)家在下單后就可以開(kāi)始評(píng)論揩晴，比如如果賣(mài)家發(fā)貨慢了，買(mǎi)家可以上去吐槽贪磺，那么‘評(píng)論comment’就不是單向依賴(lài)于‘receive收貨’行為了硫兰，而是多向依賴(lài)于‘pay付款’、‘deliver發(fā)貨’缘挽、‘receive收貨’瞄崇，那么這些actions的subState組合可能性就暴增，BizState的字典取值也會(huì)暴增壕曼，顯然，不應(yīng)當(dāng)將這么多的BizState交給OrderState來(lái)記錄等浊，而應(yīng)當(dāng)由一個(gè)獨(dú)立的數(shù)據(jù)庫(kù)字段負(fù)責(zé)記錄‘評(píng)論comment’的SubState腮郊，我們可以將這個(gè)字段取名為‘CommentState’（評(píng)論狀態(tài)），它的字典值不多筹燕，只有：‘未評(píng)論’轧飞、‘買(mǎi)家已評(píng)論’衅鹿、‘賣(mài)家已評(píng)論’；其實(shí)过咬，對(duì)于前一種需求大渤，也可以不講‘評(píng)論comment’對(duì)應(yīng)的SubState產(chǎn)生的BizState納入OrderState，因?yàn)橛脩?hù)對(duì)于評(píng)論與否其實(shí)并不是那么關(guān)心的掸绞，也就是說(shuō)‘評(píng)論comment’并不是核心業(yè)務(wù)流程泵三，為了降低核心業(yè)務(wù)流程的系統(tǒng)處理復(fù)雜度，將其從核心業(yè)務(wù)流程中剝離出來(lái)較好衔掸。
綜上烫幕，我們應(yīng)當(dāng)將‘評(píng)論comment’對(duì)應(yīng)的BizState獨(dú)立到一個(gè)字段中記錄。
‘退貨rereturn’的處理
再來(lái)看看‘退貨rereturn’行為對(duì)應(yīng)的BizState的處理群叶《魃蹋‘退貨rereturn’并不是所有訂單都會(huì)經(jīng)歷的哄尔，但是一旦涉及，則‘退貨rereturn’在業(yè)務(wù)流程上必定是單向依賴(lài)于單向依賴(lài)于‘receive收貨’捷犹，所以應(yīng)當(dāng)將‘退貨rereturn’產(chǎn)生的BizState（‘退貨中’、‘退貨成功’冕末，‘退款失敗’和‘未退貨’被忽略萍歉，見(jiàn)上面解釋?zhuān)┘{入OrderState一并記錄；這樣我們的OrderState有多了兩種字典值栓霜，這里我們不考慮一個(gè)訂單中有多種商品的情況翠桦，故把‘退貨成功'當(dāng)著終態(tài)處理，如果是一個(gè)訂單多種貨物的情況胳蛮，需要重新仔細(xì)分析销凑。加粗項(xiàng)為新增：
創(chuàng)建訂單失敗（終態(tài)）
等待買(mǎi)家付款
付款確認(rèn)中
買(mǎi)家付款失斀龃丁（終態(tài)斗幼，依賴(lài)需求而定）
買(mǎi)家付款成功
賣(mài)家已發(fā)貨
買(mǎi)家已收貨
退貨中
退貨成功（終態(tài)）
目前的訂單狀態(tài)流轉(zhuǎn)：
‘退款refund’的處理
最后來(lái)看下‘退款refund’行為對(duì)應(yīng)的BizState的處理。首先抚垄，我們需要知道‘退貨’和‘退款’是兩種不同的業(yè)務(wù)行為蜕窿，他們的關(guān)系是：通常意義上，‘退貨’必然導(dǎo)致‘退款’呆馁，但是‘退款’可以沒(méi)有‘退貨’的參與（這里不討論特殊情況桐经，比如對(duì)于虛擬貨物來(lái)講，付款成功通常以為著收貨成功浙滤，這時(shí)候就只能是在由‘退貨’導(dǎo)致‘退款’）阴挣，比如電商允許用戶(hù)付款成功后收到貨物前發(fā)起‘退款’。也就是說(shuō)‘退款refund’并不單向依賴(lài)于‘退貨rereturn’纺腊，和‘評(píng)論comment’一樣是多項(xiàng)依賴(lài)畔咧，所以茎芭，我們可以參考‘評(píng)論comment’的處理方式，單獨(dú)建立一個(gè)字段‘RefundState退款狀態(tài)’記錄‘退款refund’產(chǎn)生的BizState誓沸，這個(gè)狀態(tài)字段的字典值有：退款中梅桩，退款成功。
其他情況考慮
另外拜隧，可能還有一些增強(qiáng)型需求宿百，讓客戶(hù)體驗(yàn)更好，比如用戶(hù)可以創(chuàng)建訂單之后付款之前虹蓄，將訂單取消犀呼，或者由系統(tǒng)跑批將用戶(hù)長(zhǎng)時(shí)間未支付的訂單關(guān)閉，這會(huì)產(chǎn)生一種新的action——‘close關(guān)閉’薇组，對(duì)應(yīng)的會(huì)產(chǎn)生一種新的有意義的BizState——‘訂單關(guān)閉/取消’外臂，這個(gè)不屬于核心流程中的，且并無(wú)糾結(jié)之處律胀，不予詳細(xì)討論宋光，羅列如下：
創(chuàng)建訂單失敗（終態(tài)）
等待買(mǎi)家付款
付款確認(rèn)中
買(mǎi)家付款失斕烤（終態(tài)罪佳，依賴(lài)需求而定）
買(mǎi)家付款成功
賣(mài)家已發(fā)貨
買(mǎi)家已收貨
退貨中
退貨成功（終態(tài)）
訂單關(guān)閉（終態(tài)）
結(jié)論
綜上，我們可以得出放入數(shù)據(jù)庫(kù)’訂單狀態(tài)‘字段的標(biāo)準(zhǔn)：核心業(yè)務(wù)流程黑低，向前單向依賴(lài)赘艳。擴(kuò)展到其他業(yè)務(wù)實(shí)體是一樣的，這里說(shuō)的’訂單狀態(tài)‘字段實(shí)際是指該業(yè)務(wù)實(shí)體對(duì)應(yīng)的數(shù)據(jù)表的主業(yè)務(wù)狀態(tài)字段克握。我們把結(jié)論擴(kuò)展一下：
如果某個(gè)action屬于業(yè)務(wù)實(shí)體對(duì)應(yīng)的核心業(yè)務(wù)流程蕾管，且該action單向依賴(lài)于其前向的action，則需要將這個(gè)action產(chǎn)生的BizState放入到業(yè)務(wù)實(shí)體對(duì)應(yīng)的數(shù)據(jù)庫(kù)表的主狀態(tài)字段中記錄菩暗。
OrderState字段記錄的BizState業(yè)務(wù)狀態(tài)有10種掰曾，其中4種是終態(tài)，其余狀態(tài)為中間態(tài)停团。這些狀態(tài)的流轉(zhuǎn)關(guān)系為：
問(wèn)題二旷坦、訂單表的‘訂單狀態(tài)’字段的字典值的表示形式？
先列出可選項(xiàng)：使用數(shù)字標(biāo)識(shí)佑稠、使用多‘位’存儲(chǔ)方式標(biāo)識(shí)秒梅、使用具有明確業(yè)務(wù)含義的英文字符串標(biāo)識(shí)；對(duì)可選項(xiàng)做逐一解釋?zhuān)?br>
a舌胶、使用數(shù)字標(biāo)識(shí)——使用一個(gè)數(shù)字標(biāo)識(shí)一種狀態(tài)番电，并未要求是sequence的；如‘等待買(mǎi)家付款’表示為‘0’;
b辆琅、使用多‘位’存儲(chǔ)方式標(biāo)識(shí)——將某種行為是否發(fā)生對(duì)應(yīng)的狀態(tài)對(duì)應(yīng)到一個(gè)位上漱办，比如‘是否付款’定義在第一位，‘是否發(fā)貨’定義在第二位婉烟，‘是否收貨’定義在第三位娩井，‘是否評(píng)論’定義在第四位，則狀態(tài)‘賣(mài)家已收貨未評(píng)論’可以表示為：0111似袁；而‘等待買(mǎi)家付款’則表示為‘0000’洞辣；當(dāng)然這里的‘位’可能是二進(jìn)制的也可能是N進(jìn)制，后面我們?cè)敿?xì)討論昙衅。
c扬霜、使用具有明確業(yè)務(wù)含義的英文字符串標(biāo)識(shí)——該方案和方案a類(lèi)似，不過(guò)字典值變?yōu)榫哂忻鞔_業(yè)務(wù)含義的英文支付串而涉，如‘等待買(mǎi)家付款’表示為‘WAIT_BUYER_PAY’;
方案a是數(shù)據(jù)庫(kù)字段字典的慣用方式著瓶，簡(jiǎn)單直觀，但是有一個(gè)壞處在于：當(dāng)字典值較多時(shí)啼县，數(shù)據(jù)庫(kù)表的使用者記不住字典的含義材原，需要反復(fù)查找資料確認(rèn)；有人會(huì)說(shuō)將字典值寫(xiě)到字段的注釋里季眷，這個(gè)在實(shí)踐中不是很靠譜余蟹，通常表建立后，如果字段增加了字典值子刮，通常開(kāi)發(fā)人員都會(huì)忽略更改字典值威酒；而且在使用工具（如pl/sql）查詢(xún)數(shù)據(jù)庫(kù)時(shí)，并不會(huì)將所有字典值展示出來(lái)挺峡；
通過(guò)問(wèn)題一的分析葵孤，可知：方案b使用多‘位’存儲(chǔ)方式會(huì)增加復(fù)雜度，并沒(méi)有必要沙郭，可以通過(guò)將‘是否評(píng)論’狀態(tài)獨(dú)立成一個(gè)字段進(jìn)行表示佛呻。
方案c和方案a類(lèi)似，好處在于通過(guò)字典值直接知道業(yè)務(wù)含義病线，壞處在于會(huì)給編碼和手工查詢(xún)時(shí)帶來(lái)復(fù)雜度吓著，通常人們也記不住‘等待買(mǎi)家付款’的英文字典是‘WAIT_BUYER_PAY’，那么手動(dòng)寫(xiě)sql查詢(xún)‘等待買(mǎi)家付款’時(shí)就犯迷糊了送挑。
折中之后绑莺，我們組合方案a和方案c，得到方案d：另外建立一張字典表惕耕，存儲(chǔ)：數(shù)字形式的字典值纺裁、字典英文名稱(chēng)、字典中文簡(jiǎn)稱(chēng)、字典解釋?zhuān)挥唵螌?shí)體表的OrderState字段使用數(shù)字作為字典值欺缘。
對(duì)于方案d栋豫，看到OrderState的數(shù)字形式狀態(tài)時(shí)，可以先看看字段注釋是否有此字典的定義谚殊，如果沒(méi)有就取查下字典表丧鸯，得到字典值和含義；在編碼和手動(dòng)sql查詢(xún)時(shí)也會(huì)變得比較容易嫩絮，數(shù)字的位數(shù)畢竟要少些丛肢；建立字典表的其他好處還有：字典的解釋可以寫(xiě)的很詳細(xì)，在報(bào)表中要求展示字典中文名時(shí)剿干，也能直接從數(shù)據(jù)庫(kù)聯(lián)表查詢(xún)得到蜂怎，而不必額外做一次映射。（有參考：數(shù)據(jù)庫(kù)表設(shè)計(jì)（狀態(tài)字段））
那么對(duì)于字典數(shù)量很少的狀態(tài)字段是否有必要額外新建一張字典表呢置尔？這個(gè)根據(jù)實(shí)際情況考慮杠步，通常可以先不建撰洗，如果后續(xù)有業(yè)務(wù)場(chǎng)景需要再行創(chuàng)建也不遲篮愉。
而對(duì)于非業(yè)務(wù)實(shí)體表的系統(tǒng)日志/跑批記錄表等的狀態(tài)，則完全可以使用數(shù)字形式的字典差导，因?yàn)橥ǔ２粫?huì)有業(yè)務(wù)場(chǎng)景使用到這些字典值试躏，而且這些字典值域應(yīng)當(dāng)會(huì)比較小，所以沒(méi)有必要為他們創(chuàng)建單獨(dú)的字典表设褐。
綜上得出結(jié)論：
1颠蕴、字典值域較多、變化較多助析、報(bào)表等業(yè)務(wù)場(chǎng)景會(huì)使用到的業(yè)務(wù)實(shí)體表的業(yè)務(wù)狀態(tài)字段犀被，使用‘方案d：新建字典表’的方案處理；如‘訂單業(yè)務(wù)實(shí)體表’中的‘訂單狀態(tài)’字段外冀。
2寡键、字典值域較少、變化較少雪隧、報(bào)表等業(yè)務(wù)場(chǎng)景不會(huì)使用到的業(yè)務(wù)實(shí)體表的業(yè)務(wù)狀態(tài)字段西轩，使用‘方案a：使用數(shù)字標(biāo)識(shí)字典’的方案處理；如‘支付寶的支付流水表’的‘支付流水狀態(tài)’字段脑沿。
3藕畔、系統(tǒng)日志/跑批記錄表的狀態(tài)字段，使用‘方案a：使用數(shù)字標(biāo)識(shí)字典’的方案處理庄拇；如‘待收貨記錄表’的‘跑批狀態(tài)’字段注服。
問(wèn)題三韭邓、數(shù)據(jù)庫(kù)表的‘狀態(tài)’字段使用何種類(lèi)型
列出可選項(xiàng)：number(N)、char(N)溶弟、varchar2(N)女淑，其中N是一個(gè)長(zhǎng)度值。
這個(gè)問(wèn)題主要需要考慮使用場(chǎng)景可很、擴(kuò)展性诗力、性能、存儲(chǔ)我抠。
‘狀態(tài)’字段主要使用在查詢(xún)場(chǎng)景，且通常是‘=’或者‘in’的查詢(xún)袜茧，并沒(méi)有區(qū)間類(lèi)的查詢(xún)菜拓，故三者差別不大；
對(duì)于性能笛厦，參考[原創(chuàng)]在Oracle 10g纳鼎，Number、Char和Varchar2類(lèi)型作為主鍵裳凸，查詢(xún)效率分析 char(N)贱鄙、varchar2(N)性能優(yōu)于number(N)，故舍棄number(N)姨谷。
考慮到擴(kuò)展性逗宁，char(N)、varchar2(N)差不多梦湘；
考慮到存儲(chǔ)瞎颗，varchar2更加占用空間更小，故選擇varchar2(N)捌议。
綜上：選擇varchar2(N)作為數(shù)據(jù)庫(kù)‘狀態(tài)’字段的類(lèi)型哼拔。
問(wèn)題結(jié)論匯總
1、訂單表的‘訂單狀態(tài)’字段對(duì)應(yīng)的字典值應(yīng)當(dāng)包含哪些狀態(tài)值瓣颅？對(duì)于‘已評(píng)論’倦逐、‘已退貨’這類(lèi)狀態(tài)是放到‘訂單狀態(tài)’中？還是獨(dú)立一個(gè)字段標(biāo)識(shí)宫补？
如果某個(gè)action（行為檬姥，如支付）屬于業(yè)務(wù)實(shí)體對(duì)應(yīng)的核心業(yè)務(wù)流程，且該action單向依賴(lài)于其前向的action守谓，則需要將這個(gè)action產(chǎn)生的業(yè)務(wù)狀態(tài)放入到業(yè)務(wù)實(shí)體對(duì)應(yīng)的數(shù)據(jù)庫(kù)表的主狀態(tài)字段中記錄穿铆。
問(wèn)題中的‘已評(píng)論’由‘評(píng)論’行為產(chǎn)生，而‘評(píng)論’這個(gè)action并不是訂單業(yè)務(wù)實(shí)體的核心業(yè)務(wù)流程斋荞，且可能存在多個(gè)前向依賴(lài)action（支付荞雏、發(fā)貨、收貨等），所以應(yīng)當(dāng)獨(dú)立到一個(gè)字段標(biāo)識(shí)凤优。
問(wèn)題中的‘已退貨’由‘退貨’行為產(chǎn)生悦陋，而‘退貨’這個(gè)action是訂單業(yè)務(wù)實(shí)體的核心業(yè)務(wù)流程，用戶(hù)非常關(guān)心筑辨，且只單向依賴(lài)于‘收貨’action俺驶，所以應(yīng)當(dāng)記錄到訂單業(yè)務(wù)實(shí)體表的‘訂單狀態(tài)’字段中。
問(wèn)題中的‘已退款’由‘退款’行為產(chǎn)生棍辕，而‘退款’這個(gè)action是訂單業(yè)務(wù)實(shí)體的核心業(yè)務(wù)流程暮现，用戶(hù)非常關(guān)心，但是這個(gè)action存在多個(gè)前向依賴(lài)action（支付楚昭、發(fā)貨栖袋、收貨等），所以應(yīng)當(dāng)獨(dú)立到一個(gè)字段標(biāo)識(shí)抚太。
2塘幅、訂單表的‘訂單狀態(tài)’字段對(duì)應(yīng)的字典值如何表示？可選項(xiàng)有：使用數(shù)字標(biāo)識(shí)尿贫、使用多‘位’存儲(chǔ)方式標(biāo)識(shí)电媳、使用具有明確業(yè)務(wù)含義的英文字符串標(biāo)識(shí)；
1庆亡、字典值域較多匾乓、變化較多、報(bào)表等業(yè)務(wù)場(chǎng)景會(huì)使用到的業(yè)務(wù)實(shí)體表的業(yè)務(wù)狀態(tài)字段身冀，使用‘方案d：新建字典表’的方案處理钝尸；如‘訂單業(yè)務(wù)實(shí)體表’中的‘訂單狀態(tài)’字段。
2搂根、字典值域較少珍促、變化較少、報(bào)表等業(yè)務(wù)場(chǎng)景不會(huì)使用到的業(yè)務(wù)實(shí)體表的業(yè)務(wù)狀態(tài)字段剩愧，使用‘方案a：使用數(shù)字標(biāo)識(shí)字典’的方案處理猪叙；如‘支付寶的支付流水表’的‘支付流水狀態(tài)’字段。
3仁卷、系統(tǒng)日志/跑批記錄表的狀態(tài)字段穴翩，使用‘方案a：使用數(shù)字標(biāo)識(shí)字典’的方案處理；如‘待收貨記錄表’的‘跑批狀態(tài)’字段锦积。
3芒帕、訂單表的‘訂單狀態(tài)’字段使用何種類(lèi)型？可選項(xiàng)有：number(N)丰介、char(N)背蟆、varchar2(N);
varchar2(N)占用存儲(chǔ)更少鉴分，且具有同等的性能、擴(kuò)展性带膀，選擇varchar2(N)作為數(shù)據(jù)庫(kù)‘狀態(tài)’字段的類(lèi)型志珍。
參考資料
數(shù)據(jù)庫(kù)表設(shè)計(jì)（狀態(tài)字段）
[原創(chuàng)]在Oracle 10g，Number垛叨、Char和Varchar2類(lèi)型作為主鍵伦糯，查詢(xún)效率分析
