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系統允許開發人員更多的從以往的開發傳統架構的軟體的經驗中受益，對於技術力量不強的開發商而言不失為一個明智的選擇。