SaaS系统常见数据模型

在设计SaaS系统的数据模型时出于服务客户及减低开发成本等考虑，在数据的共享和隔离之间求得一定的平衡是必须考虑的一个重要因素。

因此一般在设计对应数据模型时不仅要考虑到技术因素，例如怎样构建一个弹性架构以支持数目不定的客户、怎样消除大容量并发访问数据库对系统性能造成的压力以及怎样允许用户按需扩展自定义数据等；同时也必须将商业因素纳入考虑范围之中，例如架构在该SaaS系统上的业务应用主要面向哪些行业的客户、目标客户对于数据存储方式是否有基于一定法律法规的要求等等。一般而言，SaaS系统的数据模型有如下三种形式：

独立数据库

将每个客户的数据单独存放在一个独立数据库是实现数据隔离的一种最为简便的解决方案。

在应用这种数据模型的SaaS系统中，大部分系统资源和应用代码还是由所有的客户所共享使用，但物理上每个客户有自己的一整套数据，而且单独存放。系统将借由元数据（Metadata）来记录哪一个数据库属于哪一个特定客户，与此同时也可以部署一定的数据库访问策略来确保即使系统处于异常状况下，客户数据也不会被其它客户意外访问到。

显而易见的是，一旦每个客户拥有其独立数据库，那他将可以轻易的对其做个性化的修改来符合其实际业务需求，而且如果系统出现异常情况需要将历史备份数据重新恢复的话，也将是一项轻而易举的工作。但是，这种数据模型的最大问题是对应的部署和维护成本非常高，硬件资源的消耗将明显高于其它两种方案，一台服务器将只能支持有限数量的客户。作为一种对应的解决技巧，系统可以定期使用例如SQLServer2003中提供的Auto-close功能将暂时没有活动连接使用的数据库实例从服务器的内存中移除，因此每台服务器可以更灵活的支持相对较多的客户访问，但这也只能在一定程度上缓解服务器的压力。

当客户由于所处行业因素或其它商业因素的限制，愿意支付额外的费用来做到数据隔离，确保数据安全，这种独立数据库的数据模型将是最为适合的解决方案。举例来说，处于银行业或医疗行业的客户们经常会有非常强的隔离数据的需求，这些客户甚至可能根本不会考虑去使用任何不提供客户独立数据库支持的SaaS系统。

共享数据库单独模式（Schema）

第二种方式则是所有客户使用同一数据库，但各自拥有一套不同的数据表组合存在于其单独的模式之内。

在这种数据模型下，当客户尝试第一次使用该SaaS系统时，系统在创建用户环境时会创建一整套默认的表结构，同时将其关联到该客户的独立模式。此时一般使用SQLCREATE命令来创建模式，同时授权一个用户帐号来访问该模式。举例来说，在SQLServer2005中可以使用如下命令：

CREATESCHEMAContosoSchemaAUTHORIZATIONContoso

接下来，系统可以使用SchemaName.TableName来访问该客户的模式：

CREATETABLEContosoSchema.Resumes(EmployeeIDintidentityprimarykey,Resumenvarchar(MAX))

一旦模式创建完毕，它将成为该客户所属用户帐号访问的的默认模式

ALTERUSERContosoWITHDEFAULT_SCHEMA=ContosoSchema

一旦默认模式设置完毕，在使用该客户的用户帐号进行SQL语句操作时就不要再使用SchemaName.TableName来指定特定的数据表，而是只需要指明表名即可。因此在系统代码内一句简单的SQL语句就可以应用于所有客户，而且每个客户仅访问到自己的模式内的数据:

SELECT*FROMResumes

这种客户独立模式的方式相对比较容易被实现，而且从数据扩展性而言，这种解决方案和独立数据库一样，客户可以相对自由的对其中的数据结构进行新增和修改。一般在最初创建该客户的模式时，系统会预先创建一整套默认的数据结构，但在那之后，客户可以对其做个性化的修改来符合其实际业务需求

这种客户独立模式的方式在数据共享和隔离之间获得了一定的平衡，它既借由数据库共享使得一台服务器就可以支持更多的客户，又在物理上实现了一定程度的数据隔离以确保数据安全。

但这种解决方案的一个不利之处就是当系统出现异常情况需要将历史备份数据重新恢复的话，流程将变得相对复杂。因为如果每个客户拥有独立数据库的话，那么只需恢复该客户最近的数据库备份即可。但在独立模式的模式下，如果简单的恢复数据库备份，那就意味着数据库内所有客户的数据将一同被恢复，无论该客户是否数据受损或需要做数据恢复与否。因此，在独立模式下，如果系统管理员希望恢复某个特定客户的数据，需要将数据库的备份解压到某临时服务器空间内，然后选定特定客户的表数据将其覆盖到系统主数据库内，一般来说，这将是一项非常复杂且耗时的工作。

这种客户独立模式的方式比较适合应用在每个客户拥有比较少的表数量的情况下，比如每个客户只有100张表或更少。这种方式毫无疑问可以在每台服务器上支持比独立数据库方式更多的客户数量，减低了服务供应商的运营成本。因此一旦SaaS系统的潜在客户们不介意其数据与其它客户的数据物理上存放在同一数据库内，这将是SaaS系统开发商一种理想的选择。

共享数据库共享模式（Schema）

第三种方式是用一个数据库和一套数据表来存放所有客户的数据。在这种模式下一个数据表内可以包含了多个客户的记录，由一个客户ID字段来确认哪条记录是属于哪个客户的。

在所有这三种数据模型中，这种共享模式的方式具有最低的硬件成本和维护成本，而且每台服务器可以支持最大数量的客户。但是由于所有客户使用同一套数据表，因此可能需要在保证数据安全性上花费更多额外的开发成本，以确保一个客户永远不会因系统异常而访问到其它客户的数据

在这种共享模式的方式下，恢复备份数据的流程类似上文提到的共享数据库但独立模式的方式，系统管理员解压备份数据至临时服务器空间，选定需要恢复的数据表，而且还需要额外的选定所需要恢复的客户记录，再导入到系统主数据库内。如果此时有大量记录需要导入，则系统的数据库服务的性能将受到很大影响，而且所有正在使用系统的客户也将受到影响。

如果SaaS服务供应商需要使用尽量少的服务器资源来服务尽可能多的客户，而且潜在客户们愿意在一定程度上放弃对数据隔离的需求来获得尽可能低廉的服务价格，则这种共享模式的方式是非常适合的。

二．开发商如何选择合适的数据模型

上述三种SaaS系统的数据模型各有其利弊，因此在为特定的SaaS应用选择适合的数据模型时，必须考虑到下列因素：

成本因素

基于数据共享设计的SaaS系统要求较高的开发成本（因为基于数据共享的系统架构相对比较复杂），因此初始投入较大，到长期来看运营维护成本则相对较少。

而基于数据隔离设计的SaaS系统则由于所需要硬件会随着支持客户数的上升而快速上升，因此相对初始投入尚可，但长期来看会有一个比较高的运营维护成本。

总体而言，选择数据共享的方式从长远角度可以为SaaS服务供应商节省大量的金钱。但远在其最终开始盈利之前，该类系统在开发中就已经需要大量的初期投入。如果无法投入所需的开发资源，或者由于商业原因需要将所开发的SaaS系统尽可能快的投放到市场，则选择数据隔离的设计模式更为恰当。

安全因素

通常在SaaS系统中会存放有很多敏感的客户业务数据，因此客户会对确保数据的安全性有很高的期望，SaaS服务供应商与客户签署的服务条款中会需要包含很多数据安全保障条款。当然，一般客户常见误解是只有采取数据隔离方式设计的SaaS系统才能完全确保数据的安全性；事实上，采取数据共享方式设计的SaaS系统一样可以在使用了一些成熟的设计模式之后，为客户提供很强的数据安全保障。

客户因素

一个SaaS系统将来所服务的潜在客户的数量、商业背景乃至其业务需求都将在很大程度上影响数据模型的选择，下面就是一些常见的可能会影响到决定的一些因素

估算该SaaS系统所期待的潜在客户数。到底是为数以百计的客户设计这一系统还是数以千计，又或者更多数量。简单的说，如果计划支持的客户数目越大，就应当越多地考虑使用数据共享的模式

估算每个客户平均使用的数据存储空间。如果使用该SaaS系统的客户可能会存储海量数据，则独立数据库模式毫无疑问是最佳选择

估算每个客户平均所需要支持的终端用户数。如果这个数字越大，则越应当考虑采用数据隔离的模式来满足终端用户的需求

决定是否为每个客户提供类似于数据备份之类的增值服务。一般而言，采用数据隔离的模式比较便于实现这类服务。

法律法规因素

公司、组织和政府机关经常需要遵守特定的法律法规的要求从而影响其选择使用哪一类的SaaS系统，而这种影响一般体现在对数据安全性的关注上。因此在设计一个SaaS系统之初，就必须对可能会影响潜在客户的法律法规做一定的调研，尤其是开发企业管理软件时，由于诸如财务、雇员管理、生产等诸多模块都会受特定地域或行业法律法规的影响，因此这些因素必须在系统设计之初就纳入考虑范围。

技能因素

对SaaS系统开发商而言，设计一个单实例多用户支持的系统架构仍然是一个很大的挑战，要想熟悉对应的开发工具，掌握相应的开发环境，也需要一支具有相当技术实力的开发团队。相对来说，选择数据隔离的模式来开发SaaS系统允许开发人员更多的从以往的开发传统架构的软件的经验中受益，对于技术力量不强的开发商而言不失为一个明智的选择。