本文嘗試通過對國內外對於基於SaaS模式的數據模型的幾種常見思路及其適用場景的研究，對這方面的若干關鍵問題進行初步的探討和分析。
因此一般在設計對應數據模型時不僅要考慮到技術因素，例如怎樣構建一個彈性架構以支持數目不定的客戶、怎樣消除大容量併發訪問數據庫對系統性能造成的壓力以及怎樣允許用戶按需擴展自定義數據等；同時也必須將商業因素納入考慮範圍之中，例如架構在該SaaS系統上的業務應用主要面向哪些行業的客戶、目標客戶對於數據存儲方式是否有基於一定法律法規的要求等等。一般而言，SaaS系統的數據模型有如下三種形式：
第二種方式則是所有客戶使用同一數據庫，但各自擁有一套不同的數據表組合存在於其單獨的模式之內。
圖3. 獨立模式（Schema）
在這種數據模型下，當客戶嘗試第一次使用該SaaS系統時，系統在創建用戶環境時會創建一整套默認的表結構，同時將其關聯到該客戶的獨立模式。此時一般使用SQL CREATE命令來創建模式，同時授權一個用戶帳號來訪問該模式。舉例來說，在SQL Server 2005 中可以使用如下命令：
CREATE SCHEMA ContosoSchema AUTHORIZATION Contoso
接下來，系統可以使用SchemaName.TableName來訪問該客戶的模式：
CREATE TABLE ContosoSchema.Resumes (EmployeeID int identity primary key, Resume nvarchar(MAX))
一旦模式創建完畢，它將成爲該客戶所屬用戶帳號訪問的的默認模式
ALTER USER Contoso WITH DEFAULT_SCHEMA = ContosoSchema
一旦默認模式設置完畢，在使用該客戶的用戶帳號進行SQL語句操作時就不要再使用SchemaName.TableName 來指定特定的數據表，而是只需要指明表名即可。因此在系統代碼內一句簡單的SQL語句就可以應用於所有客戶，而且每個客戶僅訪問到自己的模式內的數據:
SELECT * FROM Resumes
這種客戶獨立模式的方式相對比較容易被實現，而且從數據擴展性而言，這種解決方案和獨立數據庫一樣，客戶可以相對自由的對其中的數據結構進行新增和修改。一般在最初創建該客戶的模式時，系統會預先創建一整套默認的數據結構，但在那之後，客戶可以對其做個性化的修改來符合其實際業務需求
這種客戶獨立模式的方式在數據共享和隔離之間獲得了一定的平衡，它既藉由數據庫共享使得一臺服務器就可以支持更多的客戶，又在物理上實現了一定程度的數據隔離以確保數據安全。
但這種解決方案的一個不利之處就是當系統出現異常情況需要將歷史備份數據重新恢復的話，流程將變得相對複雜。因爲如果每個客戶擁有獨立數據庫的話，那麼只需恢復該客戶最近的數據庫備份即可。但在獨立模式的模式下，如果簡單的恢復數據庫備份，那就意味着數據庫內所有客戶的數據將一同被恢復，無論該客戶是否數據受損或需要做數據恢復與否。因此，在獨立模式下，如果系統管理員希望恢復某個特定客戶的數據，需要將數據庫的備份解壓到某臨時服務器空間內，然後選定特定客戶的表數據將其覆蓋到系統主數據庫內，一般來說，這將是一項非常複雜且耗時的工作。
這種客戶獨立模式的方式比較適合應用在每個客戶擁有比較少的表數量的情況下，比如每個客戶只有100張表或更少。這種方式毫無疑問可以在每臺服務器上支持比獨立數據庫方式更多的客戶數量，減低了服務供應商的運營成本。因此一旦SaaS系統的潛在客戶們不介意其數據與其它客戶的數據物理上存放在同一數據庫內，這將是SaaS系統開發商一種理想的選擇。
第三種方式是用一個數據庫和一套數據表來存放所有客戶的數據。在這種模式下一個數據表內可以包含了多個客戶的記錄，由一個客戶ID字段來確認哪條記錄是屬於哪個客戶的。
圖4. 共享模式（Schema）
在所有這三種數據模型中，這種共享模式的方式具有最低的硬件成本和維護成本，而且每臺服務器可以支持最大數量的客戶。但是由於所有客戶使用同一套數據表，因此可能需要在保證數據安全性上花費更多額外的開發成本，以確保一個客戶永遠不會因系統異常而訪問到其它客戶的數據
在這種共享模式的方式下，恢復備份數據的流程類似上文提到的共享數據庫但獨立模式的方式，系統管理員解壓備份數據至臨時服務器空間，選定需要恢復的數據表，而且還需要額外的選定所需要恢復的客戶記錄，再導入到系統主數據庫內。如果此時有大量記錄需要導入，則系統的數據庫服務的性能將受到很大影響，而且所有正在使用系統的客戶也將受到影響。
如果SaaS服務供應商需要使用盡量少的服務器資源來服務儘可能多的客戶，而且潛在客戶們願意在一定程度上放棄對數據隔離的需求來獲得儘可能低廉的服務價格，則這種共享模式的方式是非常適合的。
二． 開發商如何選擇合適的數據模型
上述三種SaaS系統的數據模型各有其利弊，因此在爲特定的SaaS應用選擇適合的數據模型時，必須考慮到下列因素：
圖5. 影響數據模型選擇的因素一覽表成本因素
基於數據共享設計的SaaS系統要求較高的開發成本（因爲基於數據共享的系統架構相對比較複雜），因此初始投入較大，到長期來看運營維護成本則相對較少。
而基於數據隔離設計的SaaS系統則由於所需要硬件會隨着支持客戶數的上升而快速上升，因此相對初始投入尚可，但長期來看會有一個比較高的運營維護成本。
總體而言，選擇數據共享的方式從長遠角度可以爲SaaS服務供應商節省大量的金錢。但遠在其最終開始盈利之前，該類系統在開發中就已經需要大量的初期投入。如果無法投入所需的開發資源，或者由於商業原因需要將所開發的SaaS系統儘可能快的投放到市場，則選擇數據隔離的設計模式更爲恰當。
安全因素
通常在SaaS系統中會存放有很多敏感的客戶業務數據，因此客戶會對確保數據的安全性有很高的期望，SaaS服務供應商與客戶簽署的服務條款中會需要包含很多數據安全保障條款。當然，一般客戶常見誤解是隻有采取數據隔離方式設計的SaaS系統才能完全確保數據的安全性；事實上，採取數據共享方式設計的SaaS系統一樣可以在使用了一些成熟的設計模式之後，爲客戶提供很強的數據安全保障。
客戶因素
一個SaaS系統將來所服務的潛在客戶的數量、商業背景乃至其業務需求都將在很大程度上影響數據模型的選擇，下面就是一些常見的可能會影響到決定的一些因素
•估算該SaaS系統所期待的潛在客戶數。到底是爲數以百計的客戶設計這一系統還是數以千計，又或者更多數量。簡單的說，如果計劃支持的客戶數目越大，就應當越多地考慮使用數據共享的模式
•估算每個客戶平均使用的數據存儲空間。如果使用該SaaS系統的客戶可能會存儲海量數據，則獨立數據庫模式毫無疑問是最佳選擇
•估算每個客戶平均所需要支持的終端用戶數。如果這個數字越大，則越應當考慮採用數據隔離的模式來滿足終端用戶的需求
•決定是否爲每個客戶提供類似於數據備份之類的增值服務。一般而言，採用數據隔離的模式比較便於實現這類服務。
圖6. 影響數據共享與隔離模式的選擇的因素
法律法規因素
公司、組織和政府機關經常需要遵守特定的法律法規的要求從而影響其選擇使用哪一類的SaaS系統，而這種影響一般體現在對數據安全性的關注上。因此在設計一個SaaS系統之初，就必須對可能會影響潛在客戶的法律法規做一定的調研，尤其是開發企業管理軟件時，由於諸如財務、僱員管理、生產等諸多模塊都會受特定地域或行業法律法規的影響，因此這些因素必須在系統設計之初就納入考慮範圍。
技能因素
對SaaS系統開發商而言，設計一個單實例多用戶支持的系統架構仍然是一個很大的挑戰，要想熟悉對應的開發工具，掌握相應的開發環境，也需要一支具有相當技術實力的開發團隊。相對來說，選擇數據隔離的模式來開發SaaS系統允許開發人員更多的從以往的開發傳統架構的軟件的經驗中受益，對於技術力量不強的開發商而言不失爲一個明智的選擇。
