一.SaaS系統(tǒng)常見數(shù)據(jù)模型

　　在設(shè)計SaaS系統(tǒng)的數(shù)據(jù)模型時出于服務(wù)客戶及減低開發(fā)成本等考慮，在數(shù)據(jù)的共享和隔離之間求得一定的平衡是必須考慮的一個重要因素。

　　因此一般在設(shè)計對應(yīng)數(shù)據(jù)模型時不僅要考慮到技術(shù)因素，例如怎樣構(gòu)建一個彈性架構(gòu)以支持?jǐn)?shù)目不定的客戶、怎樣消除大容量并發(fā)訪問數(shù)據(jù)庫對系統(tǒng)性能造成的壓力以及怎樣允許用戶按需擴(kuò)展自定義數(shù)據(jù)等;同時也必須將商業(yè)因素納入考慮范圍之中，例如架構(gòu)在該SaaS系統(tǒng)上的業(yè)務(wù)應(yīng)用主要面向哪些行業(yè)的客戶、目標(biāo)客戶對于數(shù)據(jù)存儲方式是否有基于一定法律法規(guī)的要求等等。一般而言，SaaS系統(tǒng)的數(shù)據(jù)模型有如下三種形式：

　　1.1獨(dú)立數(shù)據(jù)庫　

　　將每個客戶的數(shù)據(jù)單獨(dú)存放在一個獨(dú)立數(shù)據(jù)庫是實現(xiàn)數(shù)據(jù)隔離的一種最為簡便的解決方案。

　　在應(yīng)用這種數(shù)據(jù)模型的SaaS系統(tǒng)中，大部分系統(tǒng)資源和應(yīng)用代碼還是由所有的客戶所共享使用，但物理上每個客戶有自己的一整套數(shù)據(jù)，而且單獨(dú)存放。系統(tǒng)將借由元數(shù)據(jù)(Metadata)來記錄哪一個數(shù)據(jù)庫屬于哪一個特定客戶，與此同時也可以部署一定的數(shù)據(jù)庫訪問策略來確保即使系統(tǒng)處于異常狀況下，客戶數(shù)據(jù)也不會被其它客戶意外訪問到。

　　顯而易見的是，一旦每個客戶擁有其獨(dú)立數(shù)據(jù)庫，那他將可以輕易的對其做個性化的修改來符合其實際業(yè)務(wù)需求，而且如果系統(tǒng)出現(xiàn)異常情況需要將歷史備份數(shù)據(jù)重新恢復(fù)的話，也將是一項輕而易舉的工作。但是，這種數(shù)據(jù)模型的最大問題是對應(yīng)的部署和維護(hù)成本非常高，硬件資源的消耗將明顯高于其它兩種方案，一臺服務(wù)器將只能支持有限數(shù)量的客戶。作為一種對應(yīng)的解決技巧，系統(tǒng)可以定期使用例如SQLServer2003中提供的Auto-close功能將暫時沒有活動連接使用的數(shù)據(jù)庫實例從服務(wù)器的內(nèi)存中移除，因此每臺服務(wù)器可以更靈活的支持相對較多的客戶訪問，但這也只能在一定程度上緩解服務(wù)器的壓力。

　　當(dāng)客戶由于所處行業(yè)因素或其它商業(yè)因素的限制，愿意支付額外的費(fèi)用來做到數(shù)據(jù)隔離，確保數(shù)據(jù)安全，這種獨(dú)立數(shù)據(jù)庫的數(shù)據(jù)模型將是最為適合的解決方案。舉例來說，處于銀行業(yè)或醫(yī)療行業(yè)的客戶們經(jīng)常會有非常強(qiáng)的隔離數(shù)據(jù)的需求，這些客戶甚至可能根本不會考慮去使用任何不提供客戶獨(dú)立數(shù)據(jù)庫支持的SaaS系統(tǒng)。

　　1.2共享數(shù)據(jù)庫單獨(dú)模式(Schema)

　　第二種方式則是所有客戶使用同一數(shù)據(jù)庫，但各自擁有一套不同的數(shù)據(jù)表組合存在于其單獨(dú)的模式之內(nèi)。

　　在這種數(shù)據(jù)模型下，當(dāng)客戶嘗試第一次使用該SaaS系統(tǒng)時，系統(tǒng)在創(chuàng)建用戶環(huán)境時會創(chuàng)建一整套默認(rèn)的表結(jié)構(gòu)，同時將其關(guān)聯(lián)到該客戶的獨(dú)立模式。此時一般使用SQLCreate命令來創(chuàng)建模式，同時授權(quán)一個用戶帳號來訪問該模式。舉例來說，在SQLServer2005中可以使用如下命令：

　　CreateSCHEMAContosoSchemaAUTHORIZATIONContoso

　　接下來，系統(tǒng)可以使用SchemaName.TableName來訪問該客戶的模式：

　　Create TABLE Contoso Schema.Resumes (EmployeeID intidentity primary key,Resume nvarchar (MAX))

　　一旦模式創(chuàng)建完畢，它將成為該客戶所屬用戶帳號訪問的的默認(rèn)模式。

　　AlterUSER ContosoW ITHDEFAULT_SCHEMA=ContosoSchema

　　一旦默認(rèn)模式設(shè)置完畢，在使用該客戶的用戶帳號進(jìn)行SQL語句操作時就不要再使用Schema Name.TableName來指定特定的數(shù)據(jù)表，而是只需要指明表名即可。因此在系統(tǒng)代碼內(nèi)一句簡單的SQL語句就可以應(yīng)用于所有客戶，而且每個客戶僅訪問到自己的模式內(nèi)的數(shù)據(jù):

　　Select*FROMResumes

　　這種客戶獨(dú)立模式的方式相對比較容易被實現(xiàn)，而且從數(shù)據(jù)擴(kuò)展性而言，這種解決方案和獨(dú)立數(shù)據(jù)庫一樣，客戶可以相對自由的對其中的數(shù)據(jù)結(jié)構(gòu)進(jìn)行新增和修改。一般在最初創(chuàng)建該客戶的模式時，系統(tǒng)會預(yù)先創(chuàng)建一整套默認(rèn)的數(shù)據(jù)結(jié)構(gòu)，但在那之后，客戶可以對其做個性化的修改來符合其實際業(yè)務(wù)需求。

　　這種客戶獨(dú)立模式的方式在數(shù)據(jù)共享和隔離之間獲得了一定的平衡，它既借由數(shù)據(jù)庫共享使得一臺服務(wù)器就可以支持更多的客戶，又在物理上實現(xiàn)了一定程度的數(shù)據(jù)隔離以確保數(shù)據(jù)安全。

　　但這種解決方案的一個不利之處就是當(dāng)系統(tǒng)出現(xiàn)異常情況需要將歷史備份數(shù)據(jù)重新恢復(fù)的話，流程將變得相對復(fù)雜。因為如果每個客戶擁有獨(dú)立數(shù)據(jù)庫的話，那么只需恢復(fù)該客戶最近的數(shù)據(jù)庫備份即可。但在獨(dú)立模式的模式下，如果簡單的恢復(fù)數(shù)據(jù)庫備份，那就意味著數(shù)據(jù)庫內(nèi)所有客戶的數(shù)據(jù)將一同被恢復(fù)，無論該客戶是否數(shù)據(jù)受損或需要做數(shù)據(jù)恢復(fù)與否。因此，在獨(dú)立模式下，如果系統(tǒng)管理員希望恢復(fù)某個特定客戶的數(shù)據(jù)，需要將數(shù)據(jù)庫的備份解壓到某臨時服務(wù)器空間內(nèi)，然后選定特定客戶的表數(shù)據(jù)將其覆蓋到系統(tǒng)主數(shù)據(jù)庫內(nèi)，一般來說，這將是一項非常復(fù)雜且耗時的工作。

　　這種客戶獨(dú)立模式的方式比較適合應(yīng)用在每個客戶擁有比較少的表數(shù)量的情況下，比如每個客戶只有100張表或更少。這種方式毫無疑問可以在每臺服務(wù)器上支持比獨(dú)立數(shù)據(jù)庫方式更多的客戶數(shù)量，減低了服務(wù)供應(yīng)商的運(yùn)營成本。因此一旦SaaS系統(tǒng)的潛在客戶們不介意其數(shù)據(jù)與其它客戶的數(shù)據(jù)物理上存放在同一數(shù)據(jù)庫內(nèi)，這將是SaaS系統(tǒng)開發(fā)商一種理想的選擇。

　　1.3共享數(shù)據(jù)庫共享模式(Schema)

　　第三種方式是用一個數(shù)據(jù)庫和一套數(shù)據(jù)表來存放所有客戶的數(shù)據(jù)。在這種模式下一個數(shù)據(jù)表內(nèi)可以包含了多個客戶的記錄，由一個客戶ID字段來確認(rèn)哪條記錄是屬于哪個客戶的。

　　在所有這三種數(shù)據(jù)模型中，這種共享模式的方式具有最低的硬件成本和維護(hù)成本，而且每臺服務(wù)器可以支持最大數(shù)量的客戶。但是由于所有客戶使用同一套數(shù)據(jù)表，因此可能需要在保證數(shù)據(jù)安全性上花費(fèi)更多額外的開發(fā)成本，以確保一個客戶永遠(yuǎn)不會因系統(tǒng)異常而訪問到其它客戶的數(shù)據(jù)。

　　在這種共享模式的方式下，恢復(fù)備份數(shù)據(jù)的流程類似上文提到的共享數(shù)據(jù)庫但獨(dú)立模式的方式，系統(tǒng)管理員解壓備份數(shù)據(jù)至臨時服務(wù)器空間，選定需要恢復(fù)的數(shù)據(jù)表，而且還需要額外的選定所需要恢復(fù)的客戶記錄，再導(dǎo)入到系統(tǒng)主數(shù)據(jù)庫內(nèi)。如果此時有大量記錄需要導(dǎo)入，則系統(tǒng)的數(shù)據(jù)庫服務(wù)的性能將受到很大影響，而且所有正在使用系統(tǒng)的客戶也將受到影響。

　　如果SaaS服務(wù)供應(yīng)商需要使用盡量少的服務(wù)器資源來服務(wù)盡可能多的客戶，而且潛在客戶們愿意在一定程度上放棄對數(shù)據(jù)隔離的需求來獲得盡可能低廉的服務(wù)價格，則這種共享模式的方式是非常適合的。

　　二.開發(fā)商如何選擇合適的數(shù)據(jù)模型

　　上述三種SaaS系統(tǒng)的數(shù)據(jù)模型各有其利弊，因此在為特定的SaaS應(yīng)用選擇適合的數(shù)據(jù)模型時，必須考慮到下列因素：

　　2.1成本因素

　　基于數(shù)據(jù)共享設(shè)計的SaaS系統(tǒng)要求較高的開發(fā)成本(因為基于數(shù)據(jù)共享的系統(tǒng)架構(gòu)相對比較復(fù)雜)，因此初始投入較大，到長期來看運(yùn)營維護(hù)成本則相對較少。

　　而基于數(shù)據(jù)隔離設(shè)計的SaaS系統(tǒng)則由于所需要硬件會隨著支持客戶數(shù)的上升而快速上升，因此相對初始投入尚可，但長期來看會有一個比較高的運(yùn)營維護(hù)成本。

　　總體而言，選擇數(shù)據(jù)共享的方式從長遠(yuǎn)角度可以為SaaS服務(wù)供應(yīng)商節(jié)省大量的金錢。但遠(yuǎn)在其最終開始盈利之前，該類系統(tǒng)在開發(fā)中就已經(jīng)需要大量的初期投入。如果無法投入所需的開發(fā)資源，或者由于商業(yè)原因需要將所開發(fā)的SaaS系統(tǒng)盡可能快的投放到市場，則選擇數(shù)據(jù)隔離的設(shè)計模式更為恰當(dāng)。

　　2.2安全因素

　　通常在SaaS系統(tǒng)中會存放有很多敏感的客戶業(yè)務(wù)數(shù)據(jù)，因此客戶會對確保數(shù)據(jù)的安全性有很高的期望，SaaS服務(wù)供應(yīng)商與客戶簽署的服務(wù)條款中會需要包含很多數(shù)據(jù)安全保障條款。當(dāng)然，一般客戶常見誤解是只有采取數(shù)據(jù)隔離方式設(shè)計的SaaS系統(tǒng)才能完全確保數(shù)據(jù)的安全性;事實上，采取數(shù)據(jù)共享方式設(shè)計的SaaS系統(tǒng)一樣可以在使用了一些成熟的設(shè)計模式之后，為客戶提供很強(qiáng)的數(shù)據(jù)安全保障。

　　2.3客戶因素

　　一個SaaS系統(tǒng)將來所服務(wù)的潛在客戶的數(shù)量、商業(yè)背景乃至其業(yè)務(wù)需求都將在很大程度上影響數(shù)據(jù)模型的選擇，下面就是一些常見的可能會影響到?jīng)Q定的一些因素。

　　估算該SaaS系統(tǒng)所期待的潛在客戶數(shù)。到底是為數(shù)以百計的客戶設(shè)計這一系統(tǒng)還是數(shù)以千計，又或者更多數(shù)量。簡單的說，如果計劃支持的客戶數(shù)目越大，就應(yīng)當(dāng)越多地考慮使用數(shù)據(jù)共享的模式。

　　估算每個客戶平均使用的數(shù)據(jù)存儲空間。如果使用該SaaS系統(tǒng)的客戶可能會存儲海量數(shù)據(jù)，則獨(dú)立數(shù)據(jù)庫模式毫無疑問是最佳選擇。

　　估算每個客戶平均所需要支持的終端用戶數(shù)。如果這個數(shù)字越大，則越應(yīng)當(dāng)考慮采用數(shù)據(jù)隔離的模式來滿足終端用戶的需求。

　　決定是否為每個客戶提供類似于數(shù)據(jù)備份之類的增值服務(wù)。一般而言，采用數(shù)據(jù)隔離的模式比較便于實現(xiàn)這類服務(wù)。

　　2.4法律法規(guī)因素

　　公司、組織和政府機(jī)關(guān)經(jīng)常需要遵守特定的法律法規(guī)的要求從而影響其選擇使用哪一類的SaaS系統(tǒng)，而這種影響一般體現(xiàn)在對數(shù)據(jù)安全性的關(guān)注上。因此在設(shè)計一個SaaS系統(tǒng)之初，就必須對可能會影響潛在客戶的法律法規(guī)做一定的調(diào)研，尤其是開發(fā)企業(yè)管理軟件時，由于諸如財務(wù)、雇員管理、生產(chǎn)等諸多模塊都會受特定地域或行業(yè)法律法規(guī)的影響，因此這些因素必須在系統(tǒng)設(shè)計之初就納入考慮范圍。

　　2.5技能因素對SaaS系統(tǒng)開發(fā)商而言，設(shè)計一個單實例多用戶支持的系統(tǒng)架構(gòu)仍然是一個很大的挑戰(zhàn)，要想熟悉對應(yīng)的開發(fā)工具，掌握相應(yīng)的開發(fā)環(huán)境，也需要一支具有相當(dāng)技術(shù)實力的開發(fā)團(tuán)隊。相對來說，選擇數(shù)據(jù)隔離的模式來開發(fā)SaaS系統(tǒng)允許開發(fā)人員更多的從以往的開發(fā)傳統(tǒng)架構(gòu)的軟件的經(jīng)驗中受益，對于技術(shù)力量不強(qiáng)的開發(fā)商而言不失為一個明智的選擇。