本文結合實戰經驗，列舉了數據庫設計中一般容易犯的錯誤，以及產生的后果。

今天我們來說說B端產品失敗的主要原因之一，產品的業務建模以及數據庫設計不合理。

B端產品的數據庫設計究竟有多重要呢？怎么說呢，如果產品定位決定了一個產品有沒有市場，那么數據庫的設計很多時候決定了這個產品能夠走多遠的問題，數據庫的設計合理性是一個產品好壞最重要的指標之一。關于數據庫設計步驟以及規范的技術文章已經很多了，今天我更多偏產品以及業務層面來解釋一下其重要性。

有些從C端轉型來做B端的產品技術人可能會不以為然，數據庫設計有這么重要嗎？

實際上B端產品數據庫設計的合理性要比C端產品數據庫設計的合理性重要很多，C端產品一般來說業務相對簡單，數據之間的耦合度低，很多用非關系型數據來進行支持，數據庫的設計相對簡單，即使前期設計不當，后期調整起來問題也影響不大。而B端產品，業務復雜，數據關系聯系也多，一般用關系型數據庫來進行支持，設計好一個復雜B端產品的數據庫結構，難度是不小的。

數據庫設計一般容易犯哪些錯誤以及產生哪些后果呢，我在這里說明幾個常見的非技術規范方面的問題：

1. 數據表格中放置了大量的冗余字段

在TO C產品設計的時候，我們為了數據的讀取速度，避免關聯表格讀取信息，表格里面放置大量的冗余信息字段。

在TO B場景中，往往數據量不如TO C,大多數情況性能不會成為瓶頸，如果放置很多冗余字段，會導致后端邏輯的耦合度極其高，后續的可擴展性以及維護成本極高（B端產品因為業務復雜，可擴展性以及可維護性是極其關鍵的指標）。這里面說的冗余字段主要包含二類：

• 第一類是業務對象的屬性字段，作為基本數據進行維護。如果這些屬性字段在多個地方冗余，會導致基本數據更新的時候，需要更新其他表格大量的數據。
• 一類是一些可以被其他字段計算出來的字段，如果這些字段也保存在數據庫實體表中，會導致只要參與計算的字段發生變更的時候，都需要更新這個冗余字段，增加后臺邏輯耦合度。

2. 屬性字段關聯的對象錯誤

屬性字段需要和什么對象關聯需要反復斟酌，比如說在ERP中，常見對象有商品，顧客，訂單，庫存等等，哪一些屬性字段放在哪個業務對象是最合適？是否需要抽象出新的對象來放置屬性字段，這里面衡量各種方案的一個原則就是，看哪個方案最終可以讓綜合數據量最小，一般來說就是最佳方案。

3. 對象之間一對一，一對多，多對多關系設置的錯誤

對應關系一旦錯誤，已經有客戶上線之后，后續要調整，涉及到老客戶的數據遷移，是極其痛苦的。常見的，比如說用戶與角色的對應關系，如果用戶角色前期設置了一對一的關系，在復雜業務系統中，用戶權限復雜的時候，很有可能最終導致需要設置大量角色來滿足用戶功能權限的需求。如果允許一對多的關系，只需要配置幾個可以組合成所有用戶權限的基本角色就可以了。

4. 隨意的增加字段

經?？吹降哪Ｊ?，是需求人員拿到需求以后給到開發人員，說我需要一個什么功能，然后開發人員考慮一下實現方式，很隨意的增加了幾個字段。這個功能應該做嗎（對于功能優先級的判斷，請參考前面一篇文章《如何定義B端產品的MVP》上、下）？應該做成怎樣才是最佳方案？數據庫對未來業務的兼容性如何？這些內容都沒有考慮，如此持續研發多年，離一個好產品就越來越遠了。

這里有一個原則要注意的就是，數據庫不要隨意的增加字段，每個字段或者表格的增加要極其謹慎，因為對于產品來說，增加字段容易，對于老的版本兼容性是沒有問題。但是如果一旦增加了字段，后面要去掉或者調整，難度極大，這里面的工作量包括用戶數據的遷移，以及原來邏輯中涉及到需要調整的字段的部分。

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

數據庫的設計不當，會經常導致后續在面對新增業務的時候，很難用一套數據結構來支持多種業務情況，如果因此而產生了多個產品版本，就會比較糟糕了，會有如下后果：

1. 維護多個產品版本成本很高，如果想要統一版本涉及數據遷移，用戶教育等等，難度極大。
2. 現在都在努力挖掘客戶數據的價值，如果數據庫不統一，后續在做跨客戶的數據分析或者統計的時候難度極大。
3. 和外部第三方合作需要建立標準接口難度大。
4. 人員流動導致除了最新版本，沒有人知道老版本的功能是怎樣的。
5. 老用戶體驗差，口碑很難維持。運營部門在客戶服務的時候碰到極大難度，用戶的流失率會大大增加。

…….

上面的這些情況綜合的結果，上線的客戶越多，最后產品越走不動，所有的研發力量只能進行版本的維護，以及小修小改。當然這樣的團隊繼續做大規模的產品開發，也是不太合適的。如果已經產品面臨這樣的情況，應該怎樣來應對，后續我們再來寫對應文章進行分析。

最后要說的一點就是，現在很多公司的數據庫設計都在放在下面的普通開發身上，對于這樣核心關鍵的內容，建議要最好的人類似DataArchitect的角色來把關，如果沒有類似能力的角色，數據庫的設計要經常有架構師，核心開發，產品經理等人組成小組來周期性的進行討論和檢查。

作者：李東林（微信公眾號：SaaS產品說；微信號：jianguzhuxin），原ADP大中華區產品負責人，14年To B研發與產品設計，團隊管理經驗，主導過多款大型企業管理軟件的設計、研發、上線，也有過2年移動互聯網TO C的創業經驗。

本文由@李東林 原創發布于人人都是產品經理，未經許可，禁止轉載。

題圖來自Unsplash， 基于CC0協議。