過去，系統(tǒng)的軟件設(shè)計(jì)是以數(shù)據(jù)庫設(shè)計(jì)為核心，當(dāng)需求確定下來以后，團(tuán)隊(duì)首先開始進(jìn)行數(shù)據(jù)庫設(shè)計(jì)。因?yàn)閿?shù)據(jù)庫是各個(gè)模塊唯一的接口，當(dāng)整個(gè)團(tuán)隊(duì)將數(shù)據(jù)庫設(shè)計(jì)確定下來以后，就可以按照模塊各自獨(dú)立地進(jìn)行開發(fā)了，如下圖所示。

在上面的過程中，為了提高團(tuán)隊(duì)開發(fā)速度，盡量讓各個(gè)模塊不要交互，從而達(dá)到各自獨(dú)立開發(fā)的效果。 但是，隨著系統(tǒng)規(guī)模越來越大，業(yè)務(wù)邏輯越來越復(fù)雜，我們越來越難于保證各個(gè)模塊獨(dú)立不交互了。

隨著軟件業(yè)的不斷發(fā)展，軟件系統(tǒng)變得越來越復(fù)雜，各個(gè)模塊間的交互也越來越頻繁，這時(shí)，原有的設(shè)計(jì)過程已經(jīng)不能滿足我們的需要了。因?yàn)槿绻冗M(jìn)行數(shù)據(jù)庫設(shè)計(jì)，但數(shù)據(jù)庫設(shè)計(jì)只能描述數(shù)據(jù)結(jié)構(gòu)，而不能描述系統(tǒng)對這些數(shù)據(jù)結(jié)構(gòu)的處理。因此，在第一次對整個(gè)系統(tǒng)的梳理過程中，只能梳理系統(tǒng)的所有數(shù)據(jù)結(jié)構(gòu)，形成數(shù)據(jù)庫設(shè)計(jì)；接著，又要再次梳理整個(gè)系統(tǒng)，分析系統(tǒng)對這些數(shù)據(jù)結(jié)構(gòu)的處理過程，形成程序設(shè)計(jì)。為什么不能一次性地把整個(gè)系統(tǒng)的設(shè)計(jì)梳理到位呢？

現(xiàn)如今，我們已經(jīng)按照面向?qū)ο蟮能浖O(shè)計(jì)過程來分析設(shè)計(jì)系統(tǒng)了。 當(dāng)開始需求分析時(shí)，首先進(jìn)行用例模型的設(shè)計(jì)，分析整個(gè)系統(tǒng)要實(shí)現(xiàn)哪些功能； 接著進(jìn)行領(lǐng)域模型的設(shè)計(jì)，分析系統(tǒng)的業(yè)務(wù)實(shí)體。 在領(lǐng)域模型分析中，采用類圖的形式，每個(gè)類可以通過它的屬性來表述數(shù)據(jù)結(jié)構(gòu)，又可以通過添加方法來描述對這個(gè)數(shù)據(jù)結(jié)構(gòu)的處理。 因此，在領(lǐng)域模型的設(shè)計(jì)過程中，既完成了對數(shù)據(jù)結(jié)構(gòu)的梳理，又確定了系統(tǒng)對這些數(shù)據(jù)結(jié)構(gòu)的處理，這樣就把兩項(xiàng)工作一次性地完成了。

在這個(gè)設(shè)計(jì)過程中，其核心是領(lǐng)域模型的設(shè)計(jì)。以領(lǐng)域模型作為核心，可以指導(dǎo)系統(tǒng)的數(shù)據(jù)庫設(shè)計(jì)與程序設(shè)計(jì)，此時(shí)，數(shù)據(jù)庫設(shè)計(jì)就弱化為了領(lǐng)域?qū)ο蟪志没O(shè)計(jì)的一種實(shí)現(xiàn)方式。

一、領(lǐng)域?qū)ο蟪志没乃枷?/h4>

什么叫領(lǐng)域?qū)ο蟮某志没兀吭诋?dāng)今軟件架構(gòu)設(shè)計(jì)的主流思想中，面向?qū)ο笤O(shè)計(jì)成了主流思想，在整個(gè)系統(tǒng)運(yùn)行的過程中，所有的數(shù)據(jù)都是以領(lǐng)域?qū)ο蟮男问酱嬖诘摹Ｆ┤纾?/p>

• 要插入一條記錄就是創(chuàng)建一個(gè)領(lǐng)域?qū)ο螅?/li>
• 要更新一條記錄就是根據(jù) key 值去修改相應(yīng)的領(lǐng)域?qū)ο螅?/li>
• 刪除數(shù)據(jù)則是摧毀這個(gè)領(lǐng)域?qū)ο蟆?/li>

假如我們的服務(wù)器是一臺超級強(qiáng)大的服務(wù)器，那實(shí)際上不需要任何數(shù)據(jù)庫，直接操作這些領(lǐng)域?qū)ο缶涂梢粤耍诂F(xiàn)實(shí)世界中沒有那么強(qiáng)大的服務(wù)器。因此，必須將暫時(shí)不用的領(lǐng)域?qū)ο蟪志没鎯Φ酱疟P中，而數(shù)據(jù)庫只是這種持久化存儲的一種實(shí)現(xiàn)方式。

按照這種設(shè)計(jì)思想，我們將暫時(shí)不使用的領(lǐng)域?qū)ο髲膬?nèi)存中持久化存儲到磁盤中。當(dāng)日后需要再次使用這個(gè)領(lǐng)域?qū)ο髸r(shí)，根據(jù) key 值到數(shù)據(jù)庫查找到這條記錄，然后將其恢復(fù)成領(lǐng)域?qū)ο螅瑧?yīng)用程序就可以繼續(xù)使用它了，這就是領(lǐng)域?qū)ο蟪志没鎯Φ脑O(shè)計(jì)思想。

所以，今天的數(shù)據(jù)庫設(shè)計(jì)，實(shí)際上就是將領(lǐng)域?qū)ο蟮脑O(shè)計(jì)按照某種對應(yīng)關(guān)系，轉(zhuǎn)換成數(shù)據(jù)庫的設(shè)計(jì)。同時(shí)，隨著整個(gè)產(chǎn)業(yè)的大數(shù)據(jù)轉(zhuǎn)型，今后的數(shù)據(jù)庫設(shè)計(jì)思想也將發(fā)生巨大的轉(zhuǎn)變，有可能數(shù)據(jù)庫就不一定是關(guān)系型數(shù)據(jù)庫了，也許是 NoSQL 數(shù)據(jù)庫或者大數(shù)據(jù)平臺。數(shù)據(jù)庫的設(shè)計(jì)也不一定遵循 3NF（第三范式）了，可能會增加更多的冗余，甚至是寬表。

數(shù)據(jù)庫設(shè)計(jì)在發(fā)生劇烈的變化，但唯一不變的是領(lǐng)域?qū)ο蟆＿@樣，當(dāng)系統(tǒng)在大數(shù)據(jù)轉(zhuǎn)型時(shí)，可以保證業(yè)務(wù)代碼不變，變化的是數(shù)據(jù)訪問層（DAO）。這將使得日后大數(shù)據(jù)轉(zhuǎn)型的成本更低，讓我們更快地跟上技術(shù)快速發(fā)展的腳步。

二、領(lǐng)域模型的設(shè)計(jì)

此外，這里有個(gè)有趣的問題值得探討：領(lǐng)域模型的設(shè)計(jì)到底是誰的職責(zé)，是需求分析人員還是設(shè)計(jì)開發(fā)人員？我認(rèn)為，它是兩個(gè)角色相互協(xié)作的產(chǎn)物。而未來敏捷開發(fā)的組織形成，團(tuán)隊(duì)將更加扁平化。過去是需求分析人員做需求分析，然后交給設(shè)計(jì)人員設(shè)計(jì)開發(fā)，這種方式就使得軟件設(shè)計(jì)質(zhì)量低下而結(jié)構(gòu)臃腫。未來“大前端”的思想將支持更多設(shè)計(jì)開發(fā)人員直接參與需求分析，實(shí)現(xiàn)從需求分析到設(shè)計(jì)開發(fā)的一體化組織形式。這樣，領(lǐng)域模型就成為了設(shè)計(jì)開發(fā)人員快速理解需求的利器。

總之，**DDD 的數(shù)據(jù)庫設(shè)計(jì)實(shí)際上已經(jīng)變成了：以領(lǐng)域模型為核心，如何將領(lǐng)域模型轉(zhuǎn)換成數(shù)據(jù)庫設(shè)計(jì)的過程。**那么怎樣進(jìn)行轉(zhuǎn)換呢？在領(lǐng)域模型中是一個(gè)一個(gè)的類，而在數(shù)據(jù)庫設(shè)計(jì)中是一個(gè)一個(gè)的表，因此就是將類轉(zhuǎn)換成表的過程。

上圖是一個(gè)績效考核系統(tǒng)的領(lǐng)域模型圖，該績效考核系統(tǒng)首先進(jìn)行自動考核，發(fā)現(xiàn)一批過錯，然后再給一個(gè)機(jī)會，讓過錯責(zé)任人對自己的過錯進(jìn)行申辯。 這時(shí)，過錯責(zé)任人可以填寫一張申辯申請單，在申辯申請單中有多個(gè)明細(xì)，每個(gè)明細(xì)對應(yīng)一個(gè)過錯行為，每個(gè)過錯行為都對應(yīng)了一個(gè)過錯類型，這樣就形成了一個(gè)領(lǐng)域模型。

接著，要將這個(gè)領(lǐng)域模型轉(zhuǎn)換成數(shù)據(jù)庫設(shè)計(jì)，怎么做呢？很顯然，領(lǐng)域模型中的一個(gè)類可以轉(zhuǎn)換成數(shù)據(jù)庫中的一個(gè)表，類中的屬性可以轉(zhuǎn)換成表中的字段。但這里的關(guān)鍵是如何處理類與類之間的關(guān)系，如何轉(zhuǎn)換成表與表之間的關(guān)系。這時(shí)候，就有 5 種類型的關(guān)系需要轉(zhuǎn)換，即傳統(tǒng)的 4 種關(guān)系 + 繼承關(guān)系。

三、傳統(tǒng)的 4 種關(guān)系

傳統(tǒng)的關(guān)系包含一對一、多對一、一對多、多對多這 4 種，它們既存在于類與類之間，又存在于表與表之間，所以可以直接進(jìn)行轉(zhuǎn)換。

1、一對一關(guān)系

在以上案例中，“申辯申請單明細(xì)”與“過錯行為”就是一對“一對一”關(guān)系。在該關(guān)系中，一個(gè)“申辯申請單明細(xì)”必須要對應(yīng)一個(gè)“過錯行為”，沒有一個(gè)“過錯行為”的對應(yīng)就不能成為一個(gè)“申辯申請單明細(xì)”。這種約束在數(shù)據(jù)庫設(shè)計(jì)時(shí)，可以通過外鍵來實(shí)現(xiàn)。但是，一對一關(guān)系還有另外一個(gè)約束，那就是一個(gè)“過錯行為”最多只能有一個(gè)“申辯申請單明細(xì)”與之對應(yīng)。

也就是說，一個(gè)“過錯行為”可以沒有“申辯申請單明細(xì)”與之對應(yīng)，但如果有，最多只能有一個(gè)“申辯申請單明細(xì)”與之對應(yīng)，這個(gè)約束暗含的是一種唯一性的約束。因此，將過錯行為表中的主鍵，作為申辯申請單明細(xì)表的外鍵，并將該字段升級為申辯申請單明細(xì)表的主鍵。

2、多對一關(guān)系

是日常的分析設(shè)計(jì)中最常見的一種關(guān)系。在以上案例中，一個(gè)過錯行為對應(yīng)一個(gè)稅務(wù)人員、一個(gè)納稅人與一個(gè)過錯類型；同時(shí)，一個(gè)稅務(wù)人員，或納稅人，或過錯類型，都可以對應(yīng)多個(gè)過錯行為。它們就形成了“多對一”關(guān)系。在數(shù)據(jù)庫設(shè)計(jì)時(shí)，通過外鍵就可以建立這種“多對一”關(guān)系。因此，我們進(jìn)行了如下數(shù)據(jù)庫的設(shè)計(jì)：

多對一關(guān)系在數(shù)據(jù)庫設(shè)計(jì)上比較簡單，然而落實(shí)到程序設(shè)計(jì)時(shí)，需要好好探討一下。 比如，以上案例，在按照這樣的方式設(shè)計(jì)以后，在查詢時(shí)往往需要在查詢過錯行為的同時(shí)，顯示它們對應(yīng)的稅務(wù)人員、納稅人與過錯類型。 這時(shí)，以往的設(shè)計(jì)是增加一個(gè) join 語句。 然而，這樣的設(shè)計(jì)在隨著數(shù)據(jù)量不斷增大時(shí)，查詢性能將受到極大的影響。

也就是說，join 操作往往是關(guān)系型數(shù)據(jù)庫在面對大數(shù)據(jù)時(shí)最大的瓶頸之一。因此，一個(gè)更好的方案就是先查詢過錯行為表，分頁，然后再補(bǔ)填當(dāng)前頁的其他關(guān)聯(lián)信息。這時(shí)，就需要在“過錯行為”這個(gè)值對象中通過屬性變量，增加對稅務(wù)人員、納稅人與過錯類型等信息的引用。

3、一對多關(guān)系

該關(guān)系往往表達(dá)的是一種主-子表的關(guān)系。譬如，以上案例中的“申辯申請單”與“申辯申請單明細(xì)”就是一對“一對多”關(guān)系。除此之外，訂單與訂單明細(xì)、表單與表單明細(xì)，都是一對多關(guān)系。一對多關(guān)系在數(shù)據(jù)庫設(shè)計(jì)上比較簡單，就是在子表中增加一個(gè)外鍵去引用主表中的主鍵。比如本案例中，申辯申請單明細(xì)表通過一個(gè)外鍵去引用申辯申請單表中的主鍵，如下圖所示。

除此之外，在程序的值對象設(shè)計(jì)時(shí)，主對象中也應(yīng)當(dāng)有一個(gè)集合的屬性變量去引用子對象。 如本例中，在“申辯申請單”值對象中有一個(gè)集合屬性去引用“申辯申請單明細(xì)”。 這樣，當(dāng)通過申辯申請單號查找到某個(gè)申辯申請單時(shí)，同時(shí)就可以獲得它的所有申辯申請單明細(xì)，如下代碼所示：

public class Sbsqd {
    private Set<SbsqdMx> sbsqdMxes;
    public void setSbsqdMxes(Set<SbsqdMx> sbsqdMxes){
          this.sbsqdMxes = sbsqdMxes;
    }
    public Set<SbsqdMx> getSbsqdMxes(){
          return this.sbsqdMxes;
    }
    ……
}

4、多對多關(guān)系

比較典型的例子就是“用戶角色”與“功能權(quán)限”。一個(gè)“用戶角色”可以申請多個(gè)“功能權(quán)限”；而一個(gè)“功能權(quán)限”又可以分配給多個(gè)“用戶角色”使用，這樣就形成了一個(gè)“多對多”關(guān)系。這種多對多關(guān)系在對象設(shè)計(jì)時(shí)，可以通過一個(gè)“功能-角色關(guān)聯(lián)類”來詳細(xì)描述。因此，在數(shù)據(jù)庫設(shè)計(jì)時(shí)就可以添加一個(gè)“角色功能關(guān)聯(lián)表”，而該表的主鍵就是關(guān)系雙方的主鍵進(jìn)行的組合，形成的聯(lián)合主鍵，如下圖所示：

以上是領(lǐng)域模型和數(shù)據(jù)庫都有的 4 種關(guān)系。 因此，在數(shù)據(jù)庫設(shè)計(jì)時(shí)，直接將相應(yīng)的關(guān)系轉(zhuǎn)換成數(shù)據(jù)庫設(shè)計(jì)就可以了。 同時(shí)，在數(shù)據(jù)庫設(shè)計(jì)時(shí)還要將它們進(jìn)一步細(xì)化。 如在領(lǐng)域模型中，不論對象還是屬性，在命名時(shí)都采用中文，這樣有利于溝通與理解。 但到了數(shù)據(jù)庫設(shè)計(jì)時(shí)，就要將它們細(xì)化為英文命名，或者漢語拼音首字母，同時(shí)還要確定它們的字段類型與是否為空等其他屬性。

四、繼承關(guān)系的 3 種設(shè)計(jì)

第 5 種關(guān)系就不太一樣了：繼承關(guān)系是在領(lǐng)域模型設(shè)計(jì)中有，但在數(shù)據(jù)庫設(shè)計(jì)中卻沒有。如何將領(lǐng)域模型中的繼承關(guān)系轉(zhuǎn)換成數(shù)據(jù)庫設(shè)計(jì)呢？有 3 種方案可以選擇。

1、繼承關(guān)系的第一種方案

首先，看看以上案例。“執(zhí)法行為”通過繼承分為“正確行為”和“過錯行為”。如果這種繼承關(guān)系的子類不多（一般就 2 ~ 3 個(gè)），并且每個(gè)子類的個(gè)性化字段也不多（3 個(gè)以內(nèi)）的話，則可以使用一個(gè)表來記錄整個(gè)繼承關(guān)系。在這個(gè)表的中間有一個(gè)標(biāo)識字段，標(biāo)識表中的每條記錄到底是哪個(gè)子類，這個(gè)字段的前面部分羅列的是父類的字段，后面依次羅列各個(gè)子類的個(gè)性化字段。

采用這個(gè)方案的優(yōu)點(diǎn)是簡單，整個(gè)繼承關(guān)系的數(shù)據(jù)全部都保存在這個(gè)表里。 但是，它會造成“表稀疏”。 在該案例中，如果是一條“正確行為”的記錄，則字段“過錯類型”與“扣分”永遠(yuǎn)為空； 如果是一條“過錯行為”的記錄，則字段“加分”永遠(yuǎn)為空。 假如這個(gè)繼承關(guān)系中各子類的個(gè)性化字段很多，就會造成該表中出現(xiàn)大量字段為空，稱為“表稀疏”。 在關(guān)系型數(shù)據(jù)庫中，為空的字段是要占用空間的。 因此，這種“表稀疏”既會浪費(fèi)大量存儲空間，又會影響查詢速度，是需要極力避免的。 所以，當(dāng)子類比較多，或者子類個(gè)性化字段多的情況是不適合該方案（第一種方案）的。

2、繼承關(guān)系的第二種方案

如果執(zhí)法行為按照考核指標(biāo)的類型進(jìn)行繼承，分為“考核指標(biāo)1”“考核指標(biāo)2”“考核指標(biāo)3”……如下圖所示：

并且每個(gè)子類都有很多的個(gè)性化字段，則采用前面那個(gè)方案就不合適了。 這時(shí)，用另外兩個(gè)方案進(jìn)行數(shù)據(jù)庫設(shè)計(jì)。 其中一個(gè)方案是將每個(gè)子類都對應(yīng)到一個(gè)表，有幾個(gè)子類就有幾個(gè)表，這些表共用一個(gè)主鍵，即這幾個(gè)表的主鍵生成器是一個(gè)，某個(gè)主鍵值只能存在于某一個(gè)表中，不能存在于多個(gè)表中。 每個(gè)表的前面是父類的字段，后面羅列各個(gè)子類的字段，如下圖所示：

如果業(yè)務(wù)需求是在前端查詢時(shí)，每次只能查詢某一個(gè)指標(biāo)，那么采用這種方案就能將每次查詢落到某一個(gè)表中，方案就最合適。 但如果業(yè)務(wù)需求是要查詢某個(gè)過錯責(zé)任人涉及的所有指標(biāo)，則采用這種方案就必須要在所有的表中進(jìn)行掃描，那么查詢效率就比較低，并不適用。

3、繼承關(guān)系的第三種方案

如果業(yè)務(wù)需求是要查詢某個(gè)過錯責(zé)任人涉及的所有指標(biāo)，則更適合采用以下方案，將父類做成一個(gè)表，各個(gè)子類分別對應(yīng)各自的表（如圖所示）。這樣，當(dāng)需要查詢某個(gè)過錯責(zé)任人涉及的所有指標(biāo)時(shí)，只需要查詢父類的表就可以了。如果要查看某條記錄的詳細(xì)信息，再根據(jù)主鍵與類型字段，查詢相應(yīng)子類的個(gè)性化字段。這樣，這種方案就可以完美實(shí)現(xiàn)該業(yè)務(wù)需求。

綜上所述，將領(lǐng)域模型中的繼承關(guān)系轉(zhuǎn)換成數(shù)據(jù)庫設(shè)計(jì)有 3 種方案，并且每個(gè)方案都有各自的優(yōu)缺點(diǎn)。 因此，需要根據(jù)業(yè)務(wù)場景的特點(diǎn)與需求去評估，選擇哪個(gè)方案更適用。

五、NoSQL 數(shù)據(jù)庫的設(shè)計(jì)

前面我們講的數(shù)據(jù)庫設(shè)計(jì)，還是基于傳統(tǒng)的關(guān)系型數(shù)據(jù)庫、基于第三范式的數(shù)據(jù)庫設(shè)計(jì)。但是，隨著互聯(lián)網(wǎng)高并發(fā)與分布式技術(shù)的發(fā)展，另一種全新的數(shù)據(jù)庫類型孕育而生，那就是NoSQL 數(shù)據(jù)庫。正是由于互聯(lián)網(wǎng)應(yīng)用帶來的高并發(fā)壓力，采用關(guān)系型數(shù)據(jù)庫進(jìn)行集中式部署不能滿足這種高并發(fā)的壓力，才使得分布式 NoSQL 數(shù)據(jù)庫得到快速發(fā)展。

也正因?yàn)槿绱耍琋oSQL 數(shù)據(jù)庫與關(guān)系型數(shù)據(jù)庫的設(shè)計(jì)套路是完全不同的。關(guān)系型數(shù)據(jù)庫的設(shè)計(jì)是遵循第三范式進(jìn)行的，它使得數(shù)據(jù)庫能夠大幅度降低冗余，但又從另一個(gè)角度使得數(shù)據(jù)庫查詢需要頻繁使用 join 操作，在高并發(fā)場景下性能低下。

所以，NoSQL 數(shù)據(jù)庫的設(shè)計(jì)思想就是盡量干掉 join 操作，即將需要 join 的查詢在寫入數(shù)據(jù)庫表前先進(jìn)行 join 操作，然后直接寫到一張單表中進(jìn)行分布式存儲，這張表稱為“寬表”。這樣，在面對海量數(shù)據(jù)進(jìn)行查詢時(shí)，就不需要再進(jìn)行 join 操作，直接在這個(gè)單表中查詢。同時(shí)，因?yàn)?NoSQL 數(shù)據(jù)庫自身的特點(diǎn)，使得它在存儲為空的字段時(shí)不占用空間，不擔(dān)心“表稀疏”，不影響查詢性能。

因此，NoSQL 數(shù)據(jù)庫在設(shè)計(jì)時(shí)的套路就是，盡量在單表中存儲更多的字段，只要避免數(shù)據(jù)查詢中的 join 操作，即使出現(xiàn)大量為空的字段也無所謂了。

增值稅發(fā)票票樣圖

正因?yàn)?NoSQL 數(shù)據(jù)庫在設(shè)計(jì)上有以上特點(diǎn)，因此將領(lǐng)域模型轉(zhuǎn)換成 NoSQL 數(shù)據(jù)庫時(shí)，設(shè)計(jì)就完全不一樣了。比如，這樣一張?jiān)鲋刀惏l(fā)票，如上圖所示，在數(shù)據(jù)庫設(shè)計(jì)時(shí)就需要分為發(fā)票信息表、發(fā)票明細(xì)表與納稅人表，而在查詢時(shí)需要進(jìn)行 4 次 join 才能完成查詢。但在 NoSQL 數(shù)據(jù)庫設(shè)計(jì)時(shí)，將其設(shè)計(jì)成這樣一張表：

{ _id: ObjectId(7df78ad8902c)
  fpdm: '3700134140', fphm: '02309723‘, 
  kprq: '2016-1-25 9:22:45',
  je: 70451.28, se: 11976.72, 
  gfnsr: {
     nsrsbh: '370112582247803',
     nsrmc:'聯(lián)通華盛通信有限公司濟(jì)南分公司',…
  },
  xfnsr: {
     nsrsbh: '370112575587500',
     nsrmc:'聯(lián)通華盛通信有限公司濟(jì)南分公司',…
  },
  spmx: [
     { qdbz:'00', wp_mc:'藍(lán)牙耳機(jī) 車語者S1 藍(lán)牙耳機(jī)', sl:2, dj:68.37,… },
     { qdbz:'00', wp_mc:'車載充電器 新在線', sl:1, dj:11.11,… },
     { qdbz:'00', wp_mc:'保護(hù)殼 非尼膜屬 iPhone6 電鍍殼', sl:1, dj:24,…  }
  ]
}

在該案例中，對于“一對一”和“多對一”關(guān)系，在發(fā)票信息表中通過一個(gè)類型為“對象”的字段來存儲，比如“購方納稅人（gfnsr）”與“銷方納稅人（xfnsr）”字段。對于“一對多”和“多對多”關(guān)系，通過一個(gè)類型為“對象數(shù)組”的字段來存儲，如“商品明細(xì)（spmx）”字段。在這樣一個(gè)發(fā)票信息表中就可以完成對所有發(fā)票的查詢，無須再進(jìn)行任何 join 操作。

同樣，采用 NoSQL 數(shù)據(jù)庫怎樣實(shí)現(xiàn)繼承關(guān)系的設(shè)計(jì)呢？由于 NoSQL 數(shù)據(jù)庫自身的特點(diǎn)決定了不用擔(dān)心“表稀疏”，同時(shí)要避免 join 操作，所以比較適合采用第一個(gè)方案，即將整個(gè)繼承關(guān)系放到同一張表中進(jìn)行設(shè)計(jì)。這時(shí)，NoSQL 數(shù)據(jù)庫的每一條記錄可以有不一定完全相同的字段，可以設(shè)計(jì)成這樣：

{ _id: ObjectId(79878ad8902c),
  name: ‘Jack’,
  type: ‘parent’,
  partner: ‘Elizabeth’,
  children: [
    { name: ‘Tom’, gender: ‘male’ },
    { name: ‘Mary’, gender: ‘female’}
  ]
},
{ _id: ObjectId(79878ad8903d),
  name: ‘Bob’,
  type: ‘kid’,
  mother: ‘Anna’,
  father: ‘David’
}

以上案例是一個(gè)用戶檔案表，有兩條記錄：Jack 與 Bob。但是，Jack 的類型是“家長”，因此其個(gè)性化字段是“伴侶”與“孩子”；而 Bob 的類型是“孩子”，因此他的個(gè)性化字段是“父親”與“母親”。顯然，在 NoSQL 數(shù)據(jù)庫設(shè)計(jì)時(shí)就會變得更加靈活。

六、總結(jié)

將領(lǐng)域模型落地到系統(tǒng)設(shè)計(jì)包含 2 部分內(nèi)容，本文演練了第一部分內(nèi)容——從 DDD 落實(shí)到數(shù)據(jù)庫設(shè)計(jì)的整個(gè)過程：傳統(tǒng)的 4 種關(guān)系可以直接轉(zhuǎn)換；繼承關(guān)系有 3 種設(shè)計(jì)方案；轉(zhuǎn)換成 NoSQL 數(shù)據(jù)庫則是完全不同的思路。

有了 DDD 的指導(dǎo)，可以幫助我們理清數(shù)據(jù)間的關(guān)系，以及對數(shù)據(jù)的操作。不僅如此，在未來面對大數(shù)據(jù)轉(zhuǎn)型時(shí)更加從容。