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

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

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

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

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

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

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

一、定制字段

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

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

二、預(yù)分配字段

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

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

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

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

三、名稱值對

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

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

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

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

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

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