針對SaaS多租戶模型，本文分析了如何實現拓展數據的可配置。

針對SaaS多租戶模型，在實際運行過程中會發現不同的租戶需要保存不同的特殊字段。

例如，就拿CRM系統而言，A租戶希望能保存客戶紀念日、來源等，而這些數據對應B租戶而言并不需要。

這種系統實現過濾中并不存在，而用戶又需要被保存的數據，稱為拓展數據。顯然，不同的客戶需要保存的拓展數據可能是完全不同的。

對拓展數據的處理，在傳統模式中是完全不存在問題的，因為傳統軟件模式一個客戶對應一套軟件及數據庫實例，系統可是實現根據客戶的要求定制化數據庫實例。

但在SaaS模式，多個客戶對應同一套實例，如依舊采用傳統定制化模式，數據庫必將產生大量多余的字段，進而影響數據的性能。

針對SaaS多租戶模型，對于拓展數據，最常見的解決方案就是實現拓展數據的可配置，包含如下三種主流的解決方案。

一、定制字段

該解決方案更多還是在傳統軟件中被采用，根據用戶的實際需求，在數據表中增加相應的字段。 如系統只有一個用戶，那么定制字段可以完美的滿足用戶及技術需要。

但針對SaaS對租戶模型，如還為每一個客戶都添加字段，那么勢必會使表中字段多如牛毛，而且隨著定制字段的增多，將產生大量無意義字段，嚴重影響數據庫性能。

二、預分配字段

預分配的實現邏輯就是在設計數據表結構時，預留設計多幾個無意義的字段，根據實際運行過程所需的業務要求，為對應的字段賦予實際的業務意義。

例如A客戶需要額外留存訂單號，那么預分配A字段的對于A客戶而言保存的就是訂單號，B客戶需要額外需要座機號，那么預分配A字段對應B客戶而言就是座機號。

預分配字段在一定程度滿足租戶對于拓展數據的需求，但并不是完美的解決方案，依舊存在如下不足點：

• 可拓展性差：預分配字段數無法實時把控，預分配字段解決模式需要在數據庫設計前期就設定好預留的字段個數，預留多了容易造成浪費，預留少，不夠拓展使用。
• 數據類型難把控，對于預分配位置，可能需要存儲字符類型，也可能需要存儲日期類型，具體的類型無法把控。當然，也可以統一存成字符類型，在根據實際的業務要求，在代碼邏輯中實現類型的轉化。

三、名稱值對

引入配置元數據表的概率，數據庫表分為拓展數據表、業務數據表、配置元數據表。

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

誠然，不管是定制字段，預分配字段還是名稱值對，所針對的都是數據庫的設計。

本文主要還是介紹產品人員怎樣構建SaaS應用，對于涉及偏向技術性的問題，這里只大致介紹一下，有興趣的小伙伴可以自行查找相關資料就行了解。

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

題圖來自 Unsplash ，基于 CC0 協議