本文尝试通过对国内外对于基于SaaS模式的数据模型的几种常见思路及其适用场景的研究，对这方面的若干关键问题进行初步的探讨和分析。
一． SaaS系统常见数据模型
在设计SaaS系统的数据模型时出于服务客户及减低开发成本等考虑，在数据的共享和隔离之间求得一定的平衡是必须考虑的一个重要因素。
因此一般在设计对应数据模型时不仅要考虑到技术因素，例如怎样构建一个弹性架构以支持数目不定的客户、怎样消除大容量并发访问数据库对系统性能造成的压力以及怎样允许用户按需扩展自定义数据等；同时也必须将商业因素纳入考虑范围之中，例如架构在该SaaS系统上的业务应用主要面向哪些行业的客户、目标客户对于数据存储方式是否有基于一定法律法规的要求等等。一般而言，SaaS系统的数据模型有如下三种形式：
1.1独立数据库
将每个客户的数据单独存放在一个独立数据库是实现数据隔离的一种最为简便的解决方案。
在应用这种数据模型的SaaS系统中，大部分系统资源和应用代码还是由所有的客户所共享使用，但物理上每个客户有自己的一整套数据，而且单独存放。系统将借由元数据（Metadata）来记录哪一个数据库属于哪一个特定客户，与此同时也可以部署一定的数据库访问策略来确保即使系统处于异常状况下，客户数据也不会被其它客户意外访问到。
显而易见的是，一旦每个客户拥有其独立数据库，那他将可以轻易的对其做个性化的修改来符合其实际业务需求，而且如果系统出现异常情况需要将历史备份数据重新恢复的话，也将是一项轻而易举的工作。但是，这种数据模型的最大问题是对应的部署和维护成本非常高，硬件资源的消耗将明显高于其它两种方案，一台服务器将只能支持有限数量的客户。作为一种对应的解决技巧，系统可以定期使用例如SQL Server 2003中提供的Auto-close功能将暂时没有活动连接使用的数据库实例从服务器的内存中移除，因此每台服务器可以更灵活的支持相对较多的客户访问，但这也只能在一定程度上缓解服务器的压力。
当客户由于所处行业因素或其它商业因素的限制，愿意支付额外的费用来做到数据隔离，确保数据安全，这种独立数据库的数据模型将是最为适合的解决方案。举例来说，处于银行业或医疗行业的客户们经常会有非常强的隔离数据的需求，这些客户甚至可能根本不会考虑去使用任何不提供客户独立数据库支持的SaaS系统。
1.2共享数据库 单独模式（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系统开发商一种理想的选择。
1.3共享数据库 共享模式（Schema）
第三种方式是用一个数据库和一套数据表来存放所有客户的数据。在这种模式下一个数据表内可以包含了多个客户的记录，由一个客户ID字段来确认哪条记录是属于哪个客户的。
在所有这三种数据模型中，这种共享模式的方式具有最低的硬件成本和维护成本，而且每台服务器可以支持最大数量的客户。但是由于所有客户使用同一套数据表，因此可能需要在保证数据安全性上花费更多额外的开发成本，以确保一个客户永远不会因系统异常而访问到其它客户的数据。
在这种共享模式的方式下，恢复备份数据的流程类似上文提到的共享数据库但独立模式的方式，系统管理员解压备份数据至临时服务器空间，选定需要恢复的数据表，而且还需要额外的选定所需要恢复的客户记录，再导入到系统主数据库内。如果此时有大量记录需要导入，则系统的数据库服务的性能将受到很大影响，而且所有正在使用系统的客户也将受到影响。
如果SaaS服务供应商需要使用尽量少的服务器资源来服务尽可能多的客户，而且潜在客户们愿意在一定程度上放弃对数据隔离的需求来获得尽可能低廉的服务价格，则这种共享模式的方式是非常适合的。
