我负责开发和维护一组以类似数据为中心的Web应用程序.我当时决定的架构是，每个应用程序都有自己的数据库和web根应用程序.每个应用程序都维护一个到自己数据库的连接池，以及一个用于共享数据(登录等)的中央数据库
一位同事一直认为，这种策略不会扩展，因为有这么多不同的连接池是不可扩展的，我们应该重构数据库，以便所有不同的应用程序都使用一个单一的中央数据库，并且系统特有的任何修改都需要从该数据库中反映出来然后使用由Tomcat提供动力的单个池.他假设有很多"元数据"在网络中来回传输，以维护连接池.
我的理解是，通过适当的调整，在不同的池中只使用必要数量的连接(低容量应用程序获得的连接较少，高容量应用程序获得的连接数量较多，等等).pools的数量与connections的数量相比无关紧要，或者更正式地说，与1个30个连接的池相比，维护3个10个连接的池所需的开销差异可以忽略不计.
最初将系统拆分成一个应用程序-一个数据库的设计背后的原因是，应用程序之间可能会有差异，并且每个系统都可以根据需要对架构进行修改.同样，它消除了系统数据渗漏到其他应用程序的可能性.
不幸的是，公司里没有强有力的领导层来做出艰难的决定.虽然我的同事只是含糊其辞地支持他的担忧，但我希望确保我理解多个小型数据库/连接与一个大型数据库/连接池之间的差异.