关于一个系统应用是否使用多个数据源（连接池）的探讨

问：为什么一个应用需要多个数据源
答：有些情况下就是有多个数据源的

问：如果有这样的系统耦合太大了
答：比如一个查询应用，可能从不同数据库服务器的数据库中查询数据，这样就会在poolman.xml中配置多个数据源,不能说使用了多个数据源，系统的耦合度就增加了,两者不是一回事。

问：如果这样设计就很糟糕
答：并不是所有的应用都需要多个数据源，但是有些应用确实有这种情况，实际要求是这样的不能说这种设计就是糟糕的设计。

问：查询系统应该只有select 表的权限，很明显这样应该建一个ｃｄｃ数据库用户　其他用户表的权限只授予select 给ｃｄｃ　用户，不应该将给ｄｂｎａｍｅ　权限　这样的安全有问题
答：查询系统的账号有可能有查询权限，也有可能有其他权限，这个东西视情况而定，比如在数据交换系统中，通常不会使用生产系统的数据库用户来做数据交换，通常会另外创建只有查询权限的用户，但是没有绝对的情况。

问：如果dbname 连表的owner用户　表的什么权限都有了
答：当然我只是那查询做个例子来说明多个数据源的情况

问：一般应用连ｄｂｎａｍｅ　不应该　是表的ｏｗｎｅｒ，一般的公司都ｄｂｎａｍｅ　都连表的ｏｗｎｅｒ　实际上安全有很大问题；一个ｄｂｎａｍｅ　难道不就是一个用户吗
；虽然 不是oracle 用户，但是ｄｂｎａｍｅ　和ｏｒａｃｌｅ　一般也是一一对应的

答：dbname只是bboss持久层框架中的逻辑数据源的名字，不是oracle的用户名称，也就是poolman.xml中配置的<dbname>节点的值，两者完全是两个不同的概念。
是否使用多个数据源，是系统数据库规划问题，规划能使用几个数据库源就能使用，不能就不使用，bboss持久层提供了两套api分别对应于这两种情况。

一个dbname的定义如下，oracle定义：



这个是mysql的数据源定义：



这个是derby数据源



问：有这样情况？
答：呵呵，数据源（也就是我们通常意义上的连接池）通常都有一个dbname这个是bboss持久层框架的要求，有的数据源会对应数据库用户，有的数据源不对应数据库用户，比如derby

而且一个应用可能会操作多种数据库，比如mysql，oracle，db2，sqlserver，还有derby，等等，呵呵

问：一个应用可能同时会操作多种数据库

这耦合太大了

答：呵呵，那么，bboss持久层api的就提供了两组接口，一组是带dbname的，一组是不带的，如果一个系统中只有一个数据源，那么poolman.xml中就只配置一个数据源，反之就可以配置多个，使用不带dbname的api时，默认对应poolman.xml中的第一个数据源，使用带dbname的api时，那么就在对应的数据源上执行数据库操作。

在业务系统中可能操作多个数据源的情况是普遍存在的，这个和松耦合高内聚的软件设计思想没有必然联系的，也就是说这个和松耦合高内聚的软件设计思想没有冲突的

另外一种情况，我们在一个系统中有几个大模块，为了能够方便的解耦拆分和缓解一个数据库的大压力，我们反而会引入每个模块一个数据源，每个数据源对应一个独立的数据库服务器，当然前提是每个独立的模块之间的数据库是没有关联的，呵呵

当然，如果系统规模比较大，我们会将这些系统拆分成独立的应用部署，每个应用还是可以只配自己的对应的dbname的数据源即可，这样非常方便拆分和合并应用模块的，呵呵

问：别把系统搞成巨无霸系统了
答：那确实，不过一般情况下用不用多数据源和系统规模没有太多关系的。用多个数据源的系统不一定是大系统哦，很多小系统也有多个数据源的哦。

另外再大系统中使用多数据源，可以为访问量较大的模块分配一个独立的数据源，为访问量较小的模块分配其他的数据源，也能够使系统的性能更好。

bboss的持久层框架api尽可能地满足各种需要，至于系统怎么去使用，可以有架构师去决定，呵呵

bboss持久层相关配置文章：
持久层动态创建、启动、停止和使用多个数据源的方法

bbossgroups实现多数据库事务

bboss persistent通过jndi引用外部数据源（datasource）方法


bbossgroups持久层框架ConfigSQLExecutor组件api实例

bbossgroups 3.1SQLExecutor组件api使用实例 

bbossgroups持久层框架数据源配置文件实例

欢迎大家继续探讨

poolman 底层是c3p0 还是dbcp

架构方案要考虑最好的扩展型。没有太多约束的系统后期容易让项目变得越来越复杂，可能会与架构最初的设计南辕北辙，能提供的东西不是每个工程师都能用好，有时候，一切都要傻瓜化。

提供的dbcp，当然也可以使用外部数据源，请参考文档：
bboss persistent通过jndi引用外部数据源（datasource）方法

其实这样只是为了数据库的能够更好的迁移或者切换到其他数据库的。并不是你所想的一个系统使用多个数据库.

方便数据库迁移或者切换，那是另外范畴的问题，这里讨论的问题是多数据源指的是一个系统的不同子模块是否能够使用不同的逻辑数据源：
1.这些数据源可能只是逻辑上不同的连接池，但是物理上还是指向一个数据库或者一个数据库帐号
2.这些数据源是逻辑上不同的连接池，物理上也是不同的数据库或者不同的数据库帐号

一个项目使用多个数据库是很正常的情况,处于多种原因,数据的来源多种多样,比如文件系统,其他应用系统,或者数据库. 只要框架合理,设计规范,应用开发过程中是不必考虑数据来源的,而系统改造升级产生的数据源变迁,通过修改配置文件即可满足.

至于架构层次的设计问题,多应用服务多数据源的情况也符合设计规范,可以看成是特殊的分布式,也可以看作特殊的云

这名字取得啊，BBoss......哈哈，关注。。。

这位兄弟说的很好，确实要根据系统的实际情况来决定在项目中是否采用多数据源，千万不可上纲上线强制给系统加上多个数据源，最终导致后续的开发和维护变得异常复杂。




bboss，怎么对名字有看法啊，有啥看法能否和大家分享一下



有道理，本文探讨多数据源的必要性，顺便用bboss的持久层框架为例来说明可以利用bboss持久层的带数据源dbname的一组api来实现多数据源操作的功能，bboss构建的一个原则就是尽量简单，让每个工程师或者开发人员能够快速上手，把宝贵的时间用在重要的事情上，呵呵。

多数据源在实际项目情况中确实有被滥用的情况，如果大家有碰到这种情况，也可拿出来分享一下哦。