問：為什麼一個應用需要多個資料源
答：有些情況下就是有多個資料源的
問：如果有這樣的系統耦合太大了
答：比如一個查詢應用，可能從不同資料庫伺服器的資料庫中查詢資料，這樣就會在
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持久層架構資料源配置檔案執行個體