jackblue 2012-08-21
1、 数据库层:
数据库这一层的设计模式是很清晰的,无外乎只有3种方案:
(1) 所有客户的数据都存放在一个数据库的同一套表中, 在表中增加Company_id等标志字段,表明该记录是属于哪个客户的。
优点:数据源和数据库的管理都比较简单。和原来的应用没有差别。
缺点:数据权限比较复杂,增加程序的复杂性。如果应用比较复杂,很多数据表都需
要加入客户标志字段,很多查询都需要包括该字段,会比较麻烦。如果有遗漏,、特别是查询条件中遗漏该字段,就会造成一个客户看到另一个客户的数据。
(2) 每个客户独立一个数据库:
在应用服务器中配制不同的数据源,或者使用不同的连接池。
优点:不同客户的数据物理分离,安全性比较好。
缺点:数据库连接的利用效率不高。Performance 问题会很大
(3) 多Schema,单数据源
这个方案基本是方案2的变种。同一个数据库下可以有多个Schema
优点:除了方案2的优点以外,共享数据源或连接池,效率更高。
缺点:和方案一比较起来,数据库连接池开销会比较大
所有以上方案都是所有客户共享同一个应用(WAR或EAR)。
这里我选择方案三,并结合了方案一,对于登陆/验证/权限,所有的客户共享一个Schema,而对于业务数据,则每个客户一个Schema.
我做了200个不同的Schema,用户名和密码分别是demo1/demo1 到demo200/demo200,大家可以按照不同的用户名和密码登陆。
这台机器就是一台式机,不是专用服务器,网络也是放在我家里的小区宽带上,是通过无线路由器上的网,所以网速可能不太稳定。
后面几篇文章陆续写了实际的一些实现