SELECT*FROMResumes
这种客户独立模式的方式相对比较容易被实现,而且从数据扩展性而言,这种解决方案和独立数据库一样,客户可以相对自由的对其中的数据结构进行新增和修改。一般在最初创建该客户的模式时,系统会预先创建一整套默认的数据结构,但在那之后,客户可以对其做个性化的修改来符合其实际业务需求。
这种客户独立模式的方式在数据共享和隔离之间获得了一定的平衡,它既借由数据库共享使得一台服务器就可以支持更多的客户,又在物理上实现了一定程度的数据隔离以确保数据安全。
但这种解决方案的一个不利之处就是当系统出现异常情况需要将历史备份数据重新恢复的话,流程将变得相对复杂。因为如果每个客户拥有独立数据库的话,那么只需恢复该客户最近的数据库备份即可。但在独立模式的模式下,如果简单的恢复数据库备份,那就意味着数据库内所有客户的数据将一同被恢复,无论该客户是否数据受损或需要做数据恢复与否。因此,在独立模式下,如果系统管理员希望恢复某个特定客户的数据,需要将数据库的备份解压到某临时服务器空间内,然后选定特定客户的表数据将其覆盖到系统主数据库内,一般来说,这将是一项非常复杂且耗时的工作。
这种客户独立模式的方式比较适合应用在每个客户拥有比较少的表数量的情况下,比如每个客户只有100张表或更少。这种方式毫无疑问可以在每台服务器上支持比独立数据库方式更多的客户数量,减低了服务供应商的运营成本。因此一旦SaaS系统的潜在客户们不介意其数据与其它客户的数据物理上存放在同一数据库内,这将是SaaS系统开发商一种理想的选择。
1.3共享数据库共享模式(Schema)
第三种方式是用一个数据库和一套数据表来存放所有客户的数据。在这种模式下一个数据表内可以包含了多个客户的记录,由一个客户ID字段来确认哪条记录是属于哪个客户的。
在所有这三种数据模型中,这种共享模式的方式具有最低的硬件成本和维护成本,而且每台服务器可以支持最大数量的客户。但是由于所有客户使用同一套数据表,因此可能需要在保证数据安全性上花费更多额外的开发成本,以确保一个客户永远不会因系统异常而访问到其它客户的数据。
在这种共享模式的方式下,恢复备份数据的流程类似上文提到的共享数据库但独立模式的方式,系统管理员解压备份数据至临时服务器空间,选定需要恢复的数据表,而且还需要额外的选定所需要恢复的客户记录,再导入到系统主数据库内。如果此时有大量记录需要导入,则系统的数据库服务的性能将受到很大影响,而且所有正在使用系统的客户也将受到影响。
如果SaaS服务供应商需要使用尽量少的服务器资源来服务尽可能多的客户,而且潜在客户们愿意在一定程度上放弃对数据隔离的需求来获得尽可能低廉的服务价格,则这种共享模式的方式是非常适合的。
二.开发商如何选择合适的数据模型
上述三种SaaS系统的数据模型各有其利弊,因此在为特定的SaaS应用选择适合的数据模型时,必须考虑到下列因素:
2.1成本因素
基于数据共享设计的SaaS系统要求较高的开发成本(因为基于数据共享的系统架构相对比较复杂),因此初始投入较大,到长期来看运营维护成本则相对较少。
而基于数据隔离设计的SaaS系统则由于所需要硬件会随着支持客户数的上升而快速上升,因此相对初始投入尚可,但长期来看会有一个比较高的运营维护成本。
总体而言,选择数据共享的方式从长远角度可以为SaaS服务供应商节省大量的金钱。但远在其最终开始盈利之前,该类系统在开发中就已经需要大量的初期投入。如果无法投入所需的开发资源,或者由于商业原因需要将所开发的SaaS系统尽可能快的投放到市场,则选择数据隔离的设计模式更为恰当。