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