編輯導(dǎo)語：ER建模你知道是什么嗎？對(duì)于產(chǎn)品經(jīng)理來說必須重視ER建模工作，它決定了軟件產(chǎn)品的擴(kuò)展性和靈活性。本文作者通過例舉了某在線教育公司的ER建模的例子，讓大家在老王和小李的對(duì)話中，展現(xiàn)ER建模的魅力，同時(shí)加深對(duì)于ER建模的理解。

ER建模：Entity Relationship，也叫實(shí)體建模，是軟件工程中非常重要且核心的概念。

對(duì)于產(chǎn)品經(jīng)理，尤其是一名B端產(chǎn)品經(jīng)理，必須掌握并且重視ER建模工作。

ER建模的好壞，決定了軟件產(chǎn)品的擴(kuò)展性和靈活性。ER建模不準(zhǔn)確，有可能導(dǎo)致軟件設(shè)計(jì)缺陷，甚至帶來嚴(yán)重的業(yè)務(wù)問題。

如果將軟件產(chǎn)品設(shè)計(jì)比喻成蓋大樓，那么ER建模抽象出的實(shí)體對(duì)象就是大樓的根基，圍繞實(shí)體對(duì)象建設(shè)的應(yīng)用功能就是大樓的外貌，根基決定了大樓的結(jié)構(gòu)和功能，如果根基不穩(wěn)或錯(cuò)誤，大樓就有可能崩塌或不符合預(yù)期。

這些偏理論的敘述可能會(huì)讓大家感到困惑，接下來，我們通過一個(gè)實(shí)際案例，讓大家深刻理解ER建模的魅力。

在案例開始之前，我們?cè)偕晕?duì)ER設(shè)計(jì)相關(guān)知識(shí)，做一個(gè)非常簡(jiǎn)單的介紹。

一、什么是ER建模

軟件設(shè)計(jì)的核心要點(diǎn)，就是將客觀世界的事物，準(zhǔn)確的提煉抽象，變成計(jì)算機(jī)可以理解的面向?qū)ο蟮脑O(shè)計(jì)。

我們將客觀事物抽象成對(duì)象設(shè)計(jì)的過程，就叫ER建模，抽象出來的對(duì)象，就叫做實(shí)體（Entity），除了抽象出實(shí)體，我們還需要關(guān)心實(shí)體的屬性，以及實(shí)體之間的關(guān)系（Relationship）。

比如電商中的賬號(hào)和訂單，就是抽象出的實(shí)體，一個(gè)賬號(hào)可能有多個(gè)訂單，每個(gè)訂單只可能歸屬于一個(gè)賬號(hào)，這就是賬號(hào)和訂單之間存在的一對(duì)多關(guān)系。

除了一對(duì)多關(guān)系，實(shí)體之間可能還存在零對(duì)多，多對(duì)多的關(guān)系。

描述實(shí)體對(duì)象和關(guān)系的圖形，叫做ER圖，ER圖的呈現(xiàn)方式有很多種規(guī)范（比如UML，Chen，Crow’s Foot等等），繪制方法不重要，作為一名產(chǎn)品經(jīng)理，只需要簡(jiǎn)單清晰地表達(dá)出設(shè)計(jì)意圖即可。比如上述提到的賬號(hào)、訂單實(shí)體關(guān)系圖，可以簡(jiǎn)單繪制如下：

本文的重點(diǎn)，在于讓大家理解ER建模如何影響了產(chǎn)品方案并決定了業(yè)務(wù)，所以關(guān)于建模的一些基礎(chǔ)知識(shí)和設(shè)計(jì)方法論不展開講述。

接下來，進(jìn)入我們的案例。

二、案例：某在線教育公司的ER建模

某初創(chuàng)公司開展在線教育業(yè)務(wù)，面向低齡兒童，因?yàn)榭蛦蝺r(jià)高，成立電銷中心團(tuán)隊(duì)完成銷售工作。公司安排了資深產(chǎn)品專家老王負(fù)責(zé)整體產(chǎn)品方案設(shè)計(jì)，小李是老王的助手，初級(jí)產(chǎn)品經(jīng)理。

老王決定借這個(gè)機(jī)會(huì)鍛煉培養(yǎng)小李，因此手把手指導(dǎo)小李參與設(shè)計(jì)工作。

老王：小李啊，公司計(jì)劃開展在線教育業(yè)務(wù)，讓我們首先聚焦在客戶的模型設(shè)計(jì)部分，你可以聊聊你的想法啊。

小李：王老師，客戶建模是什么？這個(gè)問題不是很簡(jiǎn)單么，我們只需要一個(gè)C端的app，有一套賬號(hào)中心，客戶完成常規(guī)注冊(cè)后，在銷售的引導(dǎo)下下單不就可以了么？

老王：這個(gè)工作會(huì)比你預(yù)想的復(fù)雜很多，客戶模型的設(shè)計(jì)，對(duì)整個(gè)業(yè)務(wù)的開展，和系統(tǒng)的建設(shè)，都有全面的影響。慢慢我會(huì)引導(dǎo)你理解。不過你可以先基于你剛剛的說法，嘗試用我教你的ER圖，畫一個(gè)草圖出來，我們?cè)诖嘶A(chǔ)上一步步展開分析。

小李：好啊王老師，我認(rèn)為我們面對(duì)的是典型的C端客戶，只需要一個(gè)賬號(hào)對(duì)象，每個(gè)賬號(hào)下可以創(chuàng)建多個(gè)訂單，ER圖如下：

老王：很好，賬號(hào)和訂單是很常見的兩個(gè)實(shí)體。那么，客戶注冊(cè)后，會(huì)由電銷銷售人員跟進(jìn)服務(wù)，我們需要設(shè)計(jì)CRM系統(tǒng)給銷售人員使用。你認(rèn)為銷售人員在CRM中操作管理的客戶對(duì)象應(yīng)該是什么，是賬號(hào)么？

小李：我覺得銷售人員在CRM中管理操作的對(duì)象是“賬號(hào)”好像沒什么問題，但又感覺怪怪的，感覺銷售人員跟進(jìn)的應(yīng)該是客戶，而不是賬號(hào)，但我說不清楚這里邊的關(guān)系和定義。

老王：你的感覺是正確的，銷售人員在CRM系統(tǒng)中管理的應(yīng)該是客戶，而不應(yīng)該是客戶的賬號(hào)。實(shí)際在銷售管理中，我們認(rèn)為新注冊(cè)的客戶、賬號(hào)等等，都屬于銷售線索，線索就是指潛在客戶。在典型的CRM系統(tǒng)中除了線索，還有商機(jī)的概念，不過在我們這里用不到。

小李：好像這樣清晰一些了，感覺CRM系統(tǒng)和客戶的登錄賬號(hào)就沒有明顯關(guān)系嘛。

老王：也不能說沒有關(guān)系，只是我們?cè)谧鰯?shù)據(jù)建模的時(shí)候，要分清楚這些對(duì)象的概念，保證邏輯定義的清晰。在我們的業(yè)務(wù)中，可以設(shè)計(jì)線索和賬號(hào)就是一對(duì)一關(guān)系，銷售人員和線索是一對(duì)多關(guān)系，即一個(gè)銷售可以擁有多條線索，每個(gè)線索只能屬于0個(gè)或1個(gè)銷售。

小李：為什么一個(gè)線索還可能屬于0個(gè)銷售呢，這是什么意思呢？

老王：因?yàn)樵贑RM系統(tǒng)中，并不是每條線索都有銷售管理跟進(jìn)，有些線索可能是無人維護(hù)跟進(jìn)狀態(tài)，所以線索和銷售是1對(duì)多，其中的“多”，是指“0或多個(gè)”。我們將ER圖完善，如下：

小李：這個(gè)圖看起來更清晰了，背后對(duì)應(yīng)的設(shè)計(jì)思路也比較明確。不過我還是有點(diǎn)不理解，為什么非要把賬號(hào)和線索這兩個(gè)實(shí)體分開，除了邏輯上更清晰，還有什么好處呢？

老王：對(duì)實(shí)體進(jìn)行明確的建模和設(shè)計(jì)，除了邏輯上更清晰以外，還有很重要的一點(diǎn)，這樣做，可以降低軟件系統(tǒng)設(shè)計(jì)的耦合性。如何理解這句話呢？

ER模型最終會(huì)轉(zhuǎn)化成數(shù)據(jù)庫表結(jié)構(gòu)設(shè)計(jì)，線索和賬號(hào)可以分別保存在兩張數(shù)據(jù)表，進(jìn)一步講，隸屬于兩個(gè)不同的數(shù)據(jù)庫，即CRM系統(tǒng)的數(shù)據(jù)庫，和賬號(hào)中心的數(shù)據(jù)庫。我們來看下邊這張圖：

老王喝了口水，繼續(xù)說道：我在ER圖外邊繪制了兩個(gè)框，圓桶代表數(shù)據(jù)庫，圓桶外邊的矩形代表業(yè)務(wù)系統(tǒng)，可以看到，實(shí)際上我們?cè)贓R圖中描述的四個(gè)實(shí)體，分別隸屬于三個(gè)數(shù)據(jù)庫，和各自的業(yè)務(wù)系統(tǒng)。

這樣的ER圖設(shè)計(jì)，被清晰地傳導(dǎo)到數(shù)據(jù)庫底層設(shè)計(jì)，以及應(yīng)用系統(tǒng)的設(shè)計(jì)，可以保證銷售系統(tǒng)、用戶中心、訂單中心三者很好地解耦合，各自獨(dú)立，互不影響。

例如：CRM系統(tǒng)如果更新時(shí)出了問題，并不會(huì)影響到用戶中心系統(tǒng)，至少客戶還可以登錄訪問app。

而如果線索和賬號(hào)被設(shè)計(jì)成一個(gè)實(shí)體，對(duì)應(yīng)的表結(jié)構(gòu)設(shè)計(jì)可能就是一張表，就會(huì)導(dǎo)致多個(gè)應(yīng)用系統(tǒng)使用同一個(gè)數(shù)據(jù)庫底層，可能造成CRM更新一個(gè)銷售拜訪的功能，出問題影響到C端用戶登錄app。

小李：明白了，聽起來很有道理，ER建模不僅在邏輯上很清晰，還能在物理存儲(chǔ)上也很清晰。怪不得我們以前公司創(chuàng)業(yè)時(shí)做的系統(tǒng)，總說耦合在一起，非常死板，倉庫系統(tǒng)做個(gè)升級(jí)，能把銷售系統(tǒng)干趴下。

老王：很多時(shí)候系統(tǒng)耦合，都是創(chuàng)業(yè)公司為了快速上線，做的設(shè)計(jì)方案的妥協(xié)，比如各個(gè)業(yè)務(wù)系統(tǒng)做成一套代碼，一套數(shù)據(jù)庫。當(dāng)然，我在這里舉這個(gè)例子，主要是想說明ER建模對(duì)數(shù)據(jù)庫表設(shè)計(jì)、對(duì)應(yīng)用系統(tǒng)設(shè)計(jì)的傳導(dǎo)和影響。

小李：嗯嗯，這下對(duì)技術(shù)的理解又深刻一層。

老王：我們?cè)倩氐浇ＴO(shè)計(jì)本身?，F(xiàn)在的模型，依然存在很多問題。比如說，在目前的模型中，如果小朋友的爸爸媽媽都注冊(cè)了賬號(hào)，該怎么辦？

小李：聽起來沒啥問題啊，那就各自注冊(cè)唄？

老王：其實(shí)問題很嚴(yán)重，因?yàn)榘职謰寢尭髯宰?cè)后，會(huì)產(chǎn)生兩條沒有關(guān)系的銷售線索，CRM系統(tǒng)一般情況下會(huì)分配給兩個(gè)銷售跟進(jìn)。

但對(duì)于這個(gè)家庭來講，實(shí)際上只需要給孩子購買一次課程，那么，兩名銷售為了各自搞定家長(zhǎng)獲得提成，可能就會(huì)產(chǎn)生惡意競(jìng)爭(zhēng)，給客戶做出虛假的承諾，甚至給爸爸媽媽表述不一致，造成極差的客戶體驗(yàn)。

而且如果成單（客戶付費(fèi)），很難說清楚到底是哪個(gè)銷售的功勞更大，這就會(huì)造成銷售人員之間天天打架扯皮，非常不利于業(yè)務(wù)開展。

小李：有道理，那如果爸爸注冊(cè)了，媽媽再注冊(cè)，讓媽媽的線索分配給之前跟進(jìn)爸爸線索的銷售，不就可以了么？

老王：說的沒錯(cuò)，問題是，我們并不知道爸爸和媽媽是否是一家人?。课覀兊哪Ｐ驮O(shè)計(jì)，并沒有預(yù)留這樣的能力支撐。你想想該怎么修改呢？

小李（沉思中）：有了，我們可以將以前的單一賬號(hào)體系，改成子母賬號(hào)體系，賬號(hào)可以彼此建立歸屬關(guān)系，這樣如果爸爸和媽媽綁定彼此賬號(hào)，銷售人員就能夠識(shí)別同一家庭的家長(zhǎng)，就不會(huì)有沖突了。如下圖：

老王：很好，你的這個(gè)模型，在數(shù)據(jù)底層提供了能力支持，是我們?cè)趹?yīng)用層面解決銷售沖突業(yè)務(wù)問題的一個(gè)前提基礎(chǔ)。

小李：不過我還是沒想明白，這個(gè)底層模型如何支持業(yè)務(wù)，因?yàn)橐话鉉端用戶并沒有動(dòng)力在注冊(cè)時(shí)做家庭賬號(hào)關(guān)聯(lián)?。?/p>

老王：你說的很對(duì)，一般C端用戶并不會(huì)主動(dòng)去做賬號(hào)關(guān)聯(lián)，但是如果我們有這個(gè)數(shù)據(jù)底層設(shè)計(jì)的支持，就可以在應(yīng)用系統(tǒng)層面做各種功能，來解決業(yè)務(wù)問題，同時(shí)還要結(jié)合業(yè)務(wù)制度。

比如：銷售部門可以明確做出規(guī)定，所有銷售在第一次跟進(jìn)新線索時(shí)，必須先確定該賬號(hào)不是同一家庭賬號(hào)，或者不是已注冊(cè)家長(zhǎng)的其他手機(jī)號(hào)。

如果發(fā)現(xiàn)是，則在CRM系統(tǒng)中提供功能，做賬號(hào)合并，將兩個(gè)或多個(gè)賬號(hào)關(guān)聯(lián)起來，這樣和賬號(hào)一一對(duì)應(yīng)的線索，也就能梳理出關(guān)聯(lián)關(guān)系了，讓多個(gè)相關(guān)的線索被調(diào)配給同一名銷售。同時(shí)也可以在C端提供功能，引導(dǎo)家長(zhǎng)完成家庭多手機(jī)號(hào)的綁定。

正因?yàn)槲覀冊(cè)跀?shù)據(jù)建模時(shí)考慮到了這個(gè)問題，做好了數(shù)據(jù)底層設(shè)計(jì)的準(zhǔn)備工作，未來才能在應(yīng)用功能層面實(shí)現(xiàn)這些功能點(diǎn)，解決業(yè)務(wù)問題。

小李：明白了，真是神奇！如果銷售部門已經(jīng)明文規(guī)定了要確認(rèn)是否重復(fù)賬號(hào)，而銷售人員依然不遵守規(guī)定，那么即便第二個(gè)銷售跟進(jìn)開發(fā)成功，傭金依然判定屬于第一名銷售，只要規(guī)則明確，大家就必須遵守，糾紛就容易解決了。

老王：你說的很對(duì)！不過你的子母賬號(hào)的設(shè)計(jì)，可能會(huì)造成一種管理和被管理的感覺，在C端的體驗(yàn)并不是特別好，是否有其他方案呢？

小李（撓撓頭）：想不出來?。?/p>

老王：其實(shí)我們的業(yè)務(wù)、面臨的客戶結(jié)構(gòu)，就是典型的家庭結(jié)構(gòu)。在數(shù)據(jù)底層，可以按照家庭的模型來建模，在賬號(hào)之上設(shè)計(jì)一個(gè)家庭實(shí)體，賬號(hào)都在同一個(gè)層級(jí)，隸屬于某一個(gè)家庭，這樣也可以完成賬號(hào)關(guān)系的綁定和關(guān)聯(lián)。如下圖：

小李：精彩！家庭和賬號(hào)是一對(duì)多，線索和賬號(hào)一對(duì)一，這樣就能在數(shù)據(jù)底層，保證可以對(duì)多線索進(jìn)行唯一性識(shí)別！

老王：是的，實(shí)際上，賬號(hào)本身和線索、家庭關(guān)聯(lián)，也并不是很合理。賬號(hào)只代表一個(gè)用戶訪問系統(tǒng)的憑證，并不代表用戶自身。

在現(xiàn)實(shí)中，一個(gè)用戶完全可能有多個(gè)手機(jī)號(hào)，對(duì)于企業(yè)來講，理想的情況，是能夠識(shí)別唯一的客戶，以及他背后的多個(gè)手機(jī)號(hào)。所以，從建模的嚴(yán)謹(jǐn)性來講，我們還需要抽象出一個(gè)實(shí)體，就是家長(zhǎng)。修改后的ER圖如下：

小李：我不太理解，這樣做的目的是什么呢？你在圖中，也沒有將家長(zhǎng)和賬號(hào)設(shè)計(jì)成一對(duì)多?。?/p>

老王：家長(zhǎng)和賬號(hào)設(shè)計(jì)成一對(duì)多，會(huì)一定程度增加系統(tǒng)的復(fù)雜性，也會(huì)讓用戶的操作體驗(yàn)變復(fù)雜。

實(shí)際上，目前大多數(shù)互聯(lián)網(wǎng)跟公司的業(yè)務(wù)中，客戶和賬號(hào)設(shè)計(jì)成一對(duì)多，對(duì)業(yè)務(wù)價(jià)值并不是特別大，所以為了簡(jiǎn)化，都采用了一對(duì)一的設(shè)計(jì)方案，但是某些業(yè)務(wù)，就必須采用一對(duì)多設(shè)計(jì)了。

比如支付寶，通過身份證來識(shí)別唯一客戶，同時(shí)允許一個(gè)客戶注冊(cè)多個(gè)賬號(hào)（其實(shí)支付寶這樣做也是歷史原因?qū)е碌模?/p>

但是，即便是家長(zhǎng)和賬號(hào)一對(duì)一，為了保證邏輯的清晰，我們也需要將兩個(gè)實(shí)體（家長(zhǎng)和賬號(hào)）分離開，畢竟，賬號(hào)只是是登陸憑證，他不代表用戶自身。

我們可以在應(yīng)用層面將復(fù)雜的系統(tǒng)邏輯簡(jiǎn)化呈現(xiàn)，但是如果可能，就盡量在數(shù)據(jù)底層保持邏輯的嚴(yán)謹(jǐn)性，雖然會(huì)帶來底層設(shè)計(jì)的復(fù)雜度，但這可以保證系統(tǒng)在應(yīng)用層面設(shè)計(jì)的靈活性。

小李：很有道理，受教了！

老王：這個(gè)模型中，還有致命問題，會(huì)影響到業(yè)務(wù)。

小李：??？還有?。课乙詾橐呀?jīng)很完美了！

老王：目前訂單是關(guān)聯(lián)在賬號(hào)下的。如果一個(gè)家庭有一個(gè)小朋友，這樣的模型是沒問題的，如果一個(gè)家庭有多個(gè)小朋友，該怎么辦？實(shí)際上目前的模型不支持這個(gè)業(yè)務(wù)場(chǎng)景。

小李：是啊，這個(gè)問題的核心，是我們的模型中沒有小朋友的實(shí)體！

老王：進(jìn)步很快啊，那你思考下這個(gè)模型該如何完善？

小李：我想想，是不是可以這樣，在家庭下增加一個(gè)孩子實(shí)體，訂單掛在孩子實(shí)體上，系統(tǒng)默認(rèn)創(chuàng)建一個(gè)孩子，購買的訂單就掛在第一名孩子身上。如果家里有多個(gè)孩子，那么也支持家長(zhǎng)增加孩子，并且可以針對(duì)其他孩子購買訂單。ER圖修改如下：

老王：非常棒，你的這個(gè)模型，很好地解決了先前的業(yè)務(wù)問題！

小李：不過我還是有困惑，這樣做，會(huì)不會(huì)太復(fù)雜了？其實(shí)如果有多個(gè)小孩，那么讓客戶再注冊(cè)個(gè)賬號(hào)，不要合并家庭，創(chuàng)建訂單支付，不就解決了么？

老王：你說的很對(duì)，確實(shí)有變通的處理方案，但會(huì)損失客戶體驗(yàn)，并帶來其他的業(yè)務(wù)問題。

實(shí)際上，我們做產(chǎn)品設(shè)計(jì)，重要的是能夠想清楚所有的業(yè)務(wù)場(chǎng)景和問題，然后基于研發(fā)資源和實(shí)現(xiàn)周期，做出一個(gè)綜合評(píng)估后的合理方案，這是一個(gè)首先做加法，再做減法的過程。

尤其是在ER建模的過程中，必須思考的非常縝密，全面，因?yàn)槟銜?huì)發(fā)現(xiàn)，ER建模的過程，就是幫你梳理業(yè)務(wù)的過程。

確實(shí)，如果底層模型設(shè)計(jì)過于復(fù)雜，可能會(huì)造成研發(fā)工作量指數(shù)級(jí)的上升，但更重要的是，你能考慮清楚所有業(yè)務(wù)場(chǎng)景，評(píng)估不同設(shè)計(jì)的投入產(chǎn)出比，和業(yè)務(wù)人員、技術(shù)負(fù)責(zé)人一起充分溝通，最終做出一個(gè)充分評(píng)估論證的設(shè)計(jì)方案。

小李：明白了，前輩所言極是！

老王：我們回到剛剛提到的多孩場(chǎng)景，實(shí)際上，你在上圖繪制的ER模型，已經(jīng)能夠非常靈活的支持各種業(yè)務(wù)訴求。

比如說，如果一個(gè)家庭下，有兩個(gè)小朋友都購買了課程，并在某一天同時(shí)上課，而此時(shí)孩子的爸爸媽媽分別在外地，想各自分別去看兩個(gè)寶貝上課的情況（在線教育常見的監(jiān)課功能），正因?yàn)橛羞@個(gè)模型的支持，才能在C端的app做出強(qiáng)大的功能，父母各自登陸，查詢到家庭下的兩個(gè)孩子，并且分別切換看兩個(gè)孩子上課的情況。

小李：明白，確實(shí)，如果沒有這個(gè)模型，而讓家長(zhǎng)再注冊(cè)個(gè)賬號(hào)，在銷售管理上也會(huì)帶來混亂。

老王：是的。所以，這些問題，我們都要想清楚。另外有一點(diǎn)需要十分關(guān)注，ER建模最終會(huì)轉(zhuǎn)換成數(shù)據(jù)庫表設(shè)計(jì)，在軟件工程中，一旦表結(jié)構(gòu)定型，以后再想修改，是非常麻煩的事情。

比如，如果我們一上來就按照最簡(jiǎn)單的方案設(shè)計(jì)了客戶模型，那么未來有一天，想切換到上述理想模型，研發(fā)的投入上會(huì)非常巨大，甚至是無法完成的。

軟件系統(tǒng)重構(gòu)，最頭疼的問題就是如何將歷史數(shù)據(jù)遷移到新的數(shù)據(jù)結(jié)構(gòu)下邊。

小李：理解，所以，ER建模，是一個(gè)非常核心的設(shè)計(jì)工作，必須充分探討，務(wù)必謹(jǐn)慎！

老王：沒錯(cuò)。接下來，我再問你個(gè)問題，剛剛繪制的ER模型，還是有瑕疵。

小李：我暈，還有啥問題?。?/p>

老王：如果孩子也有賬號(hào)，也需要用自己的手機(jī)號(hào)登陸系統(tǒng)，你的模型該怎么調(diào)整？

小李：啊，真是，我還以為我們做的是幼兒教育，小朋友都得用爸爸媽媽的賬號(hào)登陸app完成學(xué)習(xí)。不過確實(shí)有這種可能性，如果我們的教育產(chǎn)品拓展到小學(xué)或初中，現(xiàn)在的小朋友都是有手機(jī)的。我想想，要不然，改這樣？

老王：你這么設(shè)計(jì)是沒有問題，但你不覺得抽象的實(shí)體有些冗余么，孩子和家長(zhǎng)，實(shí)際上都是“人”嘛，無非是不同年齡的“人”。

小李：我想想，呃，要不改成這樣？最終家長(zhǎng)和孩子這兩個(gè)實(shí)體，被進(jìn)一步抽象到“人”的維度，通過“人”的某個(gè)屬性來標(biāo)記是家長(zhǎng)還是孩子（甚至都不需要標(biāo)記，只需要通過年齡進(jìn)行識(shí)別，并產(chǎn)生相關(guān)的業(yè)務(wù)規(guī)則）。

不過，這樣設(shè)計(jì)及好么，會(huì)不會(huì)在邏輯上看起來清晰干凈，但是會(huì)讓工程實(shí)現(xiàn)變得復(fù)雜？嗯，這個(gè)事兒，還得找技術(shù)負(fù)責(zé)人老李好好再合計(jì)合計(jì)。

老王：對(duì)，一定要和技術(shù)負(fù)責(zé)人一起溝通探討，而且想的越復(fù)雜越好！不過，我還有問題要問你。

小李：您請(qǐng)講！

老王：在最后的這個(gè)模型中，訂單究竟應(yīng)該掛在“人”上，還是掛在“賬號(hào)”上呢？如果人和賬號(hào)是一對(duì)多關(guān)系，訂單又該怎么掛呢？家長(zhǎng)購買課程產(chǎn)生的積分應(yīng)該掛在“人”上呢，還是賬號(hào)上呢，還是“家庭”上呢？學(xué)生上課獲得的獎(jiǎng)勵(lì)應(yīng)該掛在“人”上呢，還是賬號(hào)上呢，還是“家庭”上呢？

小李：媽呀，怎么感覺無窮無盡的復(fù)雜啊，我想，這些問題，就留給我們聰明的讀者來思考吧！哈哈！

老王：我看行！

#專欄作家#

楊堃，公眾號(hào)：PM楊堃（ID：pmYangKun）。人人都是產(chǎn)品經(jīng)理專欄作家，《決勝B端》作者，12年互聯(lián)網(wǎng)研發(fā)、產(chǎn)品設(shè)計(jì)經(jīng)驗(yàn)，曾任VIPKID產(chǎn)品總監(jiān)，百度高級(jí)產(chǎn)品經(jīng)理，現(xiàn)為慢酷咨詢創(chuàng)始人兼CEO。

本文原創(chuàng)發(fā)布于人人都是產(chǎn)品經(jīng)理，未經(jīng)許可，禁止轉(zhuǎn)載

題圖來自?Unsplash，基于 CC0 協(xié)議