SaaS可配置化-數據可配置化

針對SaaS多租戶模型，在實際運行過程中會發現不同的租戶需要保存不同的特殊欄位，例如，就拿CRM系統而言，A租戶希望能保存客戶紀念日，來源等，而這些數據對應B租戶而言並不需要。這種系統實現過濾中並不存在，而用戶又需要被保存的數據，稱為拓展數據。顯然，不同的客戶需要保存的拓展數據可能是完全不同的。

對拓展數據的處理，在傳統模式中是完全不存在問題的，因為傳統軟體模式一個客戶對應一套軟體及資料庫實例，系統可是實現根據客戶的要求定製化資料庫實例。但在SaaS模式，多個客戶對應同一套實例，如依舊採用傳統定製化模式，資料庫必將產生大量多餘的欄位，進而影響數據的性能。針對SaaS多租戶模型，對於拓展數據，最常見的解決方案就是實現拓展數據的可配置，包含如下三種主流的解決方案。

1：定製欄位

該解決方案更多還是在傳統軟體中被採用，根據用戶的實際需求，在數據表中增加相應的欄位。如系統只有一個用戶，那麼定製欄位可以完美的滿足用戶及技術需要。但針對SaaS對租戶模型，如還為每一個客戶都添加欄位，那麼勢必會使表中欄位多如牛毛，而且隨著定製欄位的增多，將產生大量無意義欄位，嚴重影響資料庫性能。

2：預分配欄位

預分配的實現邏輯就是在設計數據表結構時，預留設計多幾個無意義的欄位，根據實際運行過程所需的業務要求，為對應的欄位賦予實際的業務意義，例如A客戶需要額外留存訂單號，那麼預分配A欄位的對於A客戶而言保存的就是訂單號，B客戶需要額外需要座機號，那麼預分配A欄位對應B客戶而言就是座機號。預分配欄位在一定程度滿足租戶對於拓展數據的需求，但並不是完美的解決方案，依舊存在如下不足點1：可拓展性差：預分配欄位數無法實時把控，預分配欄位解決模式需要在資料庫設計前期就設定好預留的欄位個數，預留多了容易造成浪費，預留少，不夠拓展使用。2：數據類型難把控，對於預分配位置，可能需要存儲字元類型，也可能需要存儲日期類型，具體的類型無法把控。當然，也可以統一存成字元類型，在根據實際的業務要求，在代碼邏輯中實現類型的轉化。

3：名稱值對引入配置元數據表的概率，資料庫表分為拓展數據表，業務數據表，配置元數據表。業務數據表負責存儲統一的業務邏輯數據，拓展數據表存儲根據租戶需求而新增的拓展數據，而拓展數據表與業務數據表通過元數據配置表關聯。引入元數據噢誒子表，實現拓展數據的橫向拓展，而且完全由租戶業務驅動，不造成數據的浪費及混亂。

誠然，不管是定製欄位，預分配欄位還是名稱值對，所針對的都是資料庫的設計，本文主要還是介紹產品人員怎樣構建SaaS應用，對於涉及偏向技術性的問題，這裡只大致介紹一下，有興趣的小夥伴可以自行查找相關資料就行了解。