針對SaaS多租戶模型，本文分析了如何實現(xiàn)拓展數(shù)據(jù)的可配置。

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

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

這種系統(tǒng)實現(xiàn)過濾中并不存在，而用戶又需要被保存的數(shù)據(jù)，稱為拓展數(shù)據(jù)。顯然，不同的客戶需要保存的拓展數(shù)據(jù)可能是完全不同的。

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

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

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

一、定制字段

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

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

二、預分配字段

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

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

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

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

三、名稱值對

引入配置元數(shù)據(jù)表的概率，數(shù)據(jù)庫表分為拓展數(shù)據(jù)表、業(yè)務數(shù)據(jù)表、配置元數(shù)據(jù)表。

業(yè)務數(shù)據(jù)表負責存儲統(tǒng)一 的業(yè)務邏輯數(shù)據(jù)，拓展數(shù)據(jù)表存儲根據(jù)租戶需求而新增的拓展數(shù)據(jù)，而拓展數(shù)據(jù)表與業(yè)務數(shù)據(jù)表通過元數(shù)據(jù)配置表關聯(lián)。引入元數(shù)據(jù)噢誒子表，實現(xiàn)拓展數(shù)據(jù)的橫向拓展，而且完全由租戶業(yè)務驅(qū)動，不造成數(shù)據(jù)的浪費及混亂。

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

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

本文由 @老鬼 原創(chuàng)發(fā)布于人人都是產(chǎn)品經(jīng)理。未經(jīng)許可，禁止轉載

題圖來自 Unsplash ，基于 CC0 協(xié)議