SaaS網際網路系統資料庫設計容易踩的坑

這幾年，各行各業的saas網際網路系統應用比較廣泛。2b應用的saas系統，基本上有如下特點：

在資料庫（mysql）設計之初，有2個坑比較容易踩到，將會給整個系統帶來麻煩，尤其後期的擴充套件和優化方面。

1.各個表沒有加company_id

各個表很有必要進行反正規化設計，都統一加上company_id，如：在電商訂單處理erp系統中，給訂單商品表也加上company_id

所有表加上company_id的好處：

2.垂直分表原則不合理

2b端的saas系統由於業務複雜，各類個性化需求高，這樣各個物件的屬性可能就會更多（比如: 訂單主物件可能包括賣方資訊、買方資訊、收貨人資訊、金融資訊、發票資訊、支付資訊、快遞資訊、揀貨資訊等等），所有的業務屬性都放在一張大表，也存在相應問題：

比較常見的一種垂直分表方法：按業務類別分，比如：訂單主物件，把金融資訊、支付資訊、收貨人資訊分出去，建成1對1字表。這樣做優點是開發員好理解，缺點是查詢時又得inner join回來，這樣其實也就失去了垂直分表的最大意義（效能）。

從效能考慮（否則，後期很難優化），設計時垂直分表原則應該是：會作為查詢條件的盡可能放在主表。哪怕重要資訊但不作為查詢條件的都可以放子表，更不用說資料量大的屬性和不經常訪問到的屬性了。

在整個系統中，盡量不用到join操作，基於單錶的增刪改查操作，entity訪問（架構設計中如何做到呢？且聽下回分解^_^）。