B端產(chǎn)品數(shù)據(jù)庫設(shè)計(jì)的原則

9 評(píng)論 21628 瀏覽 198 收藏 9 分鐘

本文結(jié)合實(shí)戰(zhàn)經(jīng)驗(yàn),列舉了數(shù)據(jù)庫設(shè)計(jì)中一般容易犯的錯(cuò)誤,以及產(chǎn)生的后果。

今天我們來說說B端產(chǎn)品失敗的主要原因之一,產(chǎn)品的業(yè)務(wù)建模以及數(shù)據(jù)庫設(shè)計(jì)不合理。

B端產(chǎn)品的數(shù)據(jù)庫設(shè)計(jì)究竟有多重要呢?怎么說呢,如果產(chǎn)品定位決定了一個(gè)產(chǎn)品有沒有市場(chǎng),那么數(shù)據(jù)庫的設(shè)計(jì)很多時(shí)候決定了這個(gè)產(chǎn)品能夠走多遠(yuǎn)的問題,數(shù)據(jù)庫的設(shè)計(jì)合理性是一個(gè)產(chǎn)品好壞最重要的指標(biāo)之一。關(guān)于數(shù)據(jù)庫設(shè)計(jì)步驟以及規(guī)范的技術(shù)文章已經(jīng)很多了,今天我更多偏產(chǎn)品以及業(yè)務(wù)層面來解釋一下其重要性。

有些從C端轉(zhuǎn)型來做B端的產(chǎn)品技術(shù)人可能會(huì)不以為然,數(shù)據(jù)庫設(shè)計(jì)有這么重要嗎?

實(shí)際上B端產(chǎn)品數(shù)據(jù)庫設(shè)計(jì)的合理性要比C端產(chǎn)品數(shù)據(jù)庫設(shè)計(jì)的合理性重要很多,C端產(chǎn)品一般來說業(yè)務(wù)相對(duì)簡(jiǎn)單,數(shù)據(jù)之間的耦合度低,很多用非關(guān)系型數(shù)據(jù)來進(jìn)行支持,數(shù)據(jù)庫的設(shè)計(jì)相對(duì)簡(jiǎn)單,即使前期設(shè)計(jì)不當(dāng),后期調(diào)整起來問題也影響不大。而B端產(chǎn)品,業(yè)務(wù)復(fù)雜,數(shù)據(jù)關(guān)系聯(lián)系也多,一般用關(guān)系型數(shù)據(jù)庫來進(jìn)行支持,設(shè)計(jì)好一個(gè)復(fù)雜B端產(chǎn)品的數(shù)據(jù)庫結(jié)構(gòu),難度是不小的。

數(shù)據(jù)庫設(shè)計(jì)一般容易犯哪些錯(cuò)誤以及產(chǎn)生哪些后果呢,我在這里說明幾個(gè)常見的非技術(shù)規(guī)范方面的問題:

1. 數(shù)據(jù)表格中放置了大量的冗余字段

在TO C產(chǎn)品設(shè)計(jì)的時(shí)候,我們?yōu)榱藬?shù)據(jù)的讀取速度,避免關(guān)聯(lián)表格讀取信息,表格里面放置大量的冗余信息字段。

在TO B場(chǎng)景中,往往數(shù)據(jù)量不如TO C,大多數(shù)情況性能不會(huì)成為瓶頸,如果放置很多冗余字段,會(huì)導(dǎo)致后端邏輯的耦合度極其高,后續(xù)的可擴(kuò)展性以及維護(hù)成本極高(B端產(chǎn)品因?yàn)闃I(yè)務(wù)復(fù)雜,可擴(kuò)展性以及可維護(hù)性是極其關(guān)鍵的指標(biāo))。這里面說的冗余字段主要包含二類:

  • 第一類是業(yè)務(wù)對(duì)象的屬性字段,作為基本數(shù)據(jù)進(jìn)行維護(hù)。如果這些屬性字段在多個(gè)地方冗余,會(huì)導(dǎo)致基本數(shù)據(jù)更新的時(shí)候,需要更新其他表格大量的數(shù)據(jù)。
  • 一類是一些可以被其他字段計(jì)算出來的字段,如果這些字段也保存在數(shù)據(jù)庫實(shí)體表中,會(huì)導(dǎo)致只要參與計(jì)算的字段發(fā)生變更的時(shí)候,都需要更新這個(gè)冗余字段,增加后臺(tái)邏輯耦合度。

2. 屬性字段關(guān)聯(lián)的對(duì)象錯(cuò)誤

屬性字段需要和什么對(duì)象關(guān)聯(lián)需要反復(fù)斟酌,比如說在ERP中,常見對(duì)象有商品,顧客,訂單,庫存等等,哪一些屬性字段放在哪個(gè)業(yè)務(wù)對(duì)象是最合適?是否需要抽象出新的對(duì)象來放置屬性字段,這里面衡量各種方案的一個(gè)原則就是,看哪個(gè)方案最終可以讓綜合數(shù)據(jù)量最小,一般來說就是最佳方案

3. 對(duì)象之間一對(duì)一,一對(duì)多,多對(duì)多關(guān)系設(shè)置的錯(cuò)誤

對(duì)應(yīng)關(guān)系一旦錯(cuò)誤,已經(jīng)有客戶上線之后,后續(xù)要調(diào)整,涉及到老客戶的數(shù)據(jù)遷移,是極其痛苦的。常見的,比如說用戶與角色的對(duì)應(yīng)關(guān)系,如果用戶角色前期設(shè)置了一對(duì)一的關(guān)系,在復(fù)雜業(yè)務(wù)系統(tǒng)中,用戶權(quán)限復(fù)雜的時(shí)候,很有可能最終導(dǎo)致需要設(shè)置大量角色來滿足用戶功能權(quán)限的需求。如果允許一對(duì)多的關(guān)系,只需要配置幾個(gè)可以組合成所有用戶權(quán)限的基本角色就可以了。

4. 隨意的增加字段

經(jīng)常看到的模式,是需求人員拿到需求以后給到開發(fā)人員,說我需要一個(gè)什么功能,然后開發(fā)人員考慮一下實(shí)現(xiàn)方式,很隨意的增加了幾個(gè)字段。這個(gè)功能應(yīng)該做嗎(對(duì)于功能優(yōu)先級(jí)的判斷,請(qǐng)參考前面一篇文章《如何定義B端產(chǎn)品的MVP》上、)?應(yīng)該做成怎樣才是最佳方案?數(shù)據(jù)庫對(duì)未來業(yè)務(wù)的兼容性如何?這些內(nèi)容都沒有考慮,如此持續(xù)研發(fā)多年,離一個(gè)好產(chǎn)品就越來越遠(yuǎn)了。

這里有一個(gè)原則要注意的就是,數(shù)據(jù)庫不要隨意的增加字段,每個(gè)字段或者表格的增加要極其謹(jǐn)慎,因?yàn)閷?duì)于產(chǎn)品來說,增加字段容易,對(duì)于老的版本兼容性是沒有問題。但是如果一旦增加了字段,后面要去掉或者調(diào)整,難度極大,這里面的工作量包括用戶數(shù)據(jù)的遷移,以及原來邏輯中涉及到需要調(diào)整的字段的部分。

另外對(duì)于SaaS產(chǎn)品來說,一些基本數(shù)據(jù),比如說城市,戶口類型,國(guó)家,以及一些國(guó)家,地方規(guī)定的政策等規(guī)則或者參數(shù),這樣的數(shù)據(jù)不要做成跟客戶掛鉤的數(shù)據(jù),盡量做成跨客戶的基本數(shù)據(jù)表,這樣做好處,一是數(shù)據(jù)可以統(tǒng)一,將來統(tǒng)計(jì)的時(shí)候極其方便,第二是如果需要更新,一次性更新就可以了,不需要一家家客戶的去進(jìn)行更新。

數(shù)據(jù)庫的設(shè)計(jì)不當(dāng),會(huì)經(jīng)常導(dǎo)致后續(xù)在面對(duì)新增業(yè)務(wù)的時(shí)候,很難用一套數(shù)據(jù)結(jié)構(gòu)來支持多種業(yè)務(wù)情況,如果因此而產(chǎn)生了多個(gè)產(chǎn)品版本,就會(huì)比較糟糕了,會(huì)有如下后果:

  1. 維護(hù)多個(gè)產(chǎn)品版本成本很高,如果想要統(tǒng)一版本涉及數(shù)據(jù)遷移,用戶教育等等,難度極大。
  2. 現(xiàn)在都在努力挖掘客戶數(shù)據(jù)的價(jià)值,如果數(shù)據(jù)庫不統(tǒng)一,后續(xù)在做跨客戶的數(shù)據(jù)分析或者統(tǒng)計(jì)的時(shí)候難度極大。
  3. 和外部第三方合作需要建立標(biāo)準(zhǔn)接口難度大。
  4. 人員流動(dòng)導(dǎo)致除了最新版本,沒有人知道老版本的功能是怎樣的。
  5. 老用戶體驗(yàn)差,口碑很難維持。運(yùn)營(yíng)部門在客戶服務(wù)的時(shí)候碰到極大難度,用戶的流失率會(huì)大大增加。

…….

上面的這些情況綜合的結(jié)果,上線的客戶越多,最后產(chǎn)品越走不動(dòng),所有的研發(fā)力量只能進(jìn)行版本的維護(hù),以及小修小改。當(dāng)然這樣的團(tuán)隊(duì)繼續(xù)做大規(guī)模的產(chǎn)品開發(fā),也是不太合適的。如果已經(jīng)產(chǎn)品面臨這樣的情況,應(yīng)該怎樣來應(yīng)對(duì),后續(xù)我們?cè)賮韺憣?duì)應(yīng)文章進(jìn)行分析。

最后要說的一點(diǎn)就是,現(xiàn)在很多公司的數(shù)據(jù)庫設(shè)計(jì)都在放在下面的普通開發(fā)身上,對(duì)于這樣核心關(guān)鍵的內(nèi)容,建議要最好的人類似DataArchitect的角色來把關(guān),如果沒有類似能力的角色,數(shù)據(jù)庫的設(shè)計(jì)要經(jīng)常有架構(gòu)師,核心開發(fā),產(chǎn)品經(jīng)理等人組成小組來周期性的進(jìn)行討論和檢查。

 

作者:李東林(微信公眾號(hào):SaaS產(chǎn)品說;微信號(hào):jianguzhuxin),原ADP大中華區(qū)產(chǎn)品負(fù)責(zé)人,14年To B研發(fā)與產(chǎn)品設(shè)計(jì),團(tuán)隊(duì)管理經(jīng)驗(yàn),主導(dǎo)過多款大型企業(yè)管理軟件的設(shè)計(jì)、研發(fā)、上線,也有過2年移動(dòng)互聯(lián)網(wǎng)TO C的創(chuàng)業(yè)經(jīng)驗(yàn)。

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

題圖來自Unsplash, 基于CC0協(xié)議。

更多精彩內(nèi)容,請(qǐng)關(guān)注人人都是產(chǎn)品經(jīng)理微信公眾號(hào)或下載App
評(píng)論
評(píng)論請(qǐng)登錄
  1. 像推薦權(quán)重分的計(jì)算涉及到數(shù)據(jù)庫數(shù)據(jù)的計(jì)算,若前期不早計(jì)算出來進(jìn)行保存,那會(huì)存在進(jìn)入該頁面會(huì)存在數(shù)據(jù)加載慢的問題。但是每次計(jì)算保存,又會(huì)存在數(shù)據(jù)庫冗余的情況,是不是說這時(shí)候的計(jì)算的數(shù)據(jù)是虛擬保存,過24小時(shí)后進(jìn)行清理

    來自浙江 回復(fù)
  2. 樓主寫的好專業(yè),質(zhì)量超棒但是作為一個(gè)新手產(chǎn)品還是花了好久時(shí)間詢問了開發(fā)和產(chǎn)品同事才理解里面的內(nèi)容。
    有個(gè)小小的建議真切希望樓主可以加入一些更通俗易懂的示例輔助,讓我們這種新手可以快速的get到樓主想要表達(dá)的內(nèi)容及實(shí)操時(shí)的標(biāo)準(zhǔn);因?yàn)槌醪嚼斫庖饬x其實(shí)還簡(jiǎn)單些但是在之后的實(shí)操中把我找到實(shí)操的標(biāo)準(zhǔn)就比較難控制的太嚴(yán)不好、放的太松了也不好這就很煩惱了,明明是根據(jù)大佬的規(guī)則來操作的為什么還是會(huì)出問題呢~~可能就是我們理解的不夠透徹只存在于初步理解。
    ??狗頭保命

    來自江蘇 回復(fù)
  3. 有更新關(guān)于冗余字段解決方案沒?

    來自湖北 回復(fù)
  4. 歡迎大家關(guān)注公眾號(hào)saas產(chǎn)品說

    回復(fù)
  5. 樓主寫得不錯(cuò)

    來自廣東 回復(fù)
  6. 現(xiàn)實(shí)往往是很殘酷的!DBA 現(xiàn)在很多變成數(shù)據(jù)庫的運(yùn)維了!

    來自遼寧 回復(fù)
  7. 作為ERP的產(chǎn)品經(jīng)理,這方面的內(nèi)容是真的深有感觸,當(dāng)?shù)讓記]有設(shè)計(jì)好,后續(xù)需要調(diào)整起來會(huì)非常的麻煩。所以每次都需求都會(huì)竟可能的和技術(shù)一起溝通,形成最優(yōu)的方案。

    來自廣東 回復(fù)
  8. 作為ERP研發(fā)的pm,深有感觸

    回復(fù)
  9. 數(shù)據(jù)庫基本知識(shí),對(duì)于小白很實(shí)用

    回復(fù)