SaaS可配置化:數據可配置化
針對SaaS多租戶模型,本文分析了如何實現拓展數據的可配置。
針對SaaS多租戶模型,在實際運行過程中會發現不同的租戶需要保存不同的特殊字段。
例如,就拿CRM系統而言,A租戶希望能保存客戶紀念日、來源等,而這些數據對應B租戶而言并不需要。
這種系統實現過濾中并不存在,而用戶又需要被保存的數據,稱為拓展數據。顯然,不同的客戶需要保存的拓展數據可能是完全不同的。
對拓展數據的處理,在傳統模式中是完全不存在問題的,因為傳統軟件模式一個客戶對應一套軟件及數據庫實例,系統可是實現根據客戶的要求定制化數據庫實例。
但在SaaS模式,多個客戶對應同一套實例,如依舊采用傳統定制化模式,數據庫必將產生大量多余的字段,進而影響數據的性能。
針對SaaS多租戶模型,對于拓展數據,最常見的解決方案就是實現拓展數據的可配置,包含如下三種主流的解決方案。
一、定制字段
該解決方案更多還是在傳統軟件中被采用,根據用戶的實際需求,在數據表中增加相應的字段。 如系統只有一個用戶,那么定制字段可以完美的滿足用戶及技術需要。
但針對SaaS對租戶模型,如還為每一個客戶都添加字段,那么勢必會使表中字段多如牛毛,而且隨著定制字段的增多,將產生大量無意義字段,嚴重影響數據庫性能。
二、預分配字段
預分配的實現邏輯就是在設計數據表結構時,預留設計多幾個無意義的字段,根據實際運行過程所需的業務要求,為對應的字段賦予實際的業務意義。
例如A客戶需要額外留存訂單號,那么預分配A字段的對于A客戶而言保存的就是訂單號,B客戶需要額外需要座機號,那么預分配A字段對應B客戶而言就是座機號。
預分配字段在一定程度滿足租戶對于拓展數據的需求,但并不是完美的解決方案,依舊存在如下不足點:
- 可拓展性差:預分配字段數無法實時把控,預分配字段解決模式需要在數據庫設計前期就設定好預留的字段個數,預留多了容易造成浪費,預留少,不夠拓展使用。
- 數據類型難把控,對于預分配位置,可能需要存儲字符類型,也可能需要存儲日期類型,具體的類型無法把控。當然,也可以統一存成字符類型,在根據實際的業務要求,在代碼邏輯中實現類型的轉化。
三、名稱值對
引入配置元數據表的概率,數據庫表分為拓展數據表、業務數據表、配置元數據表。
業務數據表負責存儲統一 的業務邏輯數據,拓展數據表存儲根據租戶需求而新增的拓展數據,而拓展數據表與業務數據表通過元數據配置表關聯。引入元數據噢誒子表,實現拓展數據的橫向拓展,而且完全由租戶業務驅動,不造成數據的浪費及混亂。
誠然,不管是定制字段,預分配字段還是名稱值對,所針對的都是數據庫的設計。
本文主要還是介紹產品人員怎樣構建SaaS應用,對于涉及偏向技術性的問題,這里只大致介紹一下,有興趣的小伙伴可以自行查找相關資料就行了解。
本文由 @老鬼 原創發布于人人都是產品經理。未經許可,禁止轉載
題圖來自 Unsplash ,基于 CC0 協議
如果能運用在低代碼平臺,那是不是可以解決定制字段的問題
贊! 名值對看似靈活 也固然有其不足。尤其進行一些統計查詢時
您好,非常感謝!我們現在就是采用的這個方式,只是評審的時候,每個租戶的表單字段不一致,前端需要寫N個頁面,這個有什么解決辦法嗎
把不同租戶的表單進行抽象,進行組件化和模版化,再根據不同租戶單獨配置不同的表單樣式
點贊點贊!
有接觸過預分配字段,當時感覺有點蠢…但是沒想到‘名稱值對’這種方案…
有沒有第三方的專門做數據和權限配置的服務商?
同求
最近碰到的問題是怎么實現后臺可配置點和后臺接口的靈活標準
文章所做的小結非常有閱讀價值,希望作者能就Saas系列寫出更多文章
期待作者詳細說下第三種方案-名稱值對,目前SaaS產品中做的最火熱的應該就是美國的salesforce CRM產品了,他們是否也是通過該方案呢
意猶未盡,剛好最近思考后臺如何在靈活性下保證前臺的用戶體驗。