SaaS模式实现架构实例分析=数据库层的设计

1、  数据库层:

数据库这一层的设计模式是很清晰的,无外乎只有3种方案:

(1)       所有客户的数据都存放在一个数据库的同一套表中, 在表中增加Company_id等标志字段,表明该记录是属于哪个客户的。

      优点:数据源和数据库的管理都比较简单。和原来的应用没有差别。

缺点:数据权限比较复杂,增加程序的复杂性。如果应用比较复杂,很多数据表都需

要加入客户标志字段,很多查询都需要包括该字段,会比较麻烦。如果有遗漏,、特别是查询条件中遗漏该字段,就会造成一个客户看到另一个客户的数据。

(2)       每个客户独立一个数据库:

在应用服务器中配制不同的数据源,或者使用不同的连接池。

优点:不同客户的数据物理分离,安全性比较好。

      缺点:数据库连接的利用效率不高。Performance 问题会很大

(3)       多Schema,单数据源

这个方案基本是方案2的变种。同一个数据库下可以有多个Schema

优点:除了方案2的优点以外,共享数据源或连接池,效率更高。

缺点:和方案一比较起来,数据库连接池开销会比较大

 

所有以上方案都是所有客户共享同一个应用(WAR或EAR)。

 

 

这里我选择方案三,并结合了方案一,对于登陆/验证/权限,所有的客户共享一个Schema,而对于业务数据,则每个客户一个Schema.

 

我做了200个不同的Schema,用户名和密码分别是demo1/demo1 到demo200/demo200,大家可以按照不同的用户名和密码登陆。

 

这台机器就是一台式机,不是专用服务器,网络也是放在我家里的小区宽带上,是通过无线路由器上的网,所以网速可能不太稳定。

  • 1
    点赞
  • 4
    收藏
    觉得还不错? 一键收藏
  • 2
    评论

“相关推荐”对你有帮助么?

  • 非常没帮助
  • 没帮助
  • 一般
  • 有帮助
  • 非常有帮助
提交
评论 2
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值