我负责开发和维护一组围绕相似数据的Web应用程序。我当时决定的体系结构是，每个应用程序都将拥有自己的数据库和Web根应用程序。每个应用程序都维护一个连接池到其自己的数据库和一个用于共享数据（登录等）的中央数据库。

一位同事一直认为该策略将无法扩展，因为拥有这么多不同的连接池将无法扩展，并且我们应该重构数据库，以便所有不同的应用程序都使用单个中央数据库，并且任何可能的修改都是系统唯一的特性需要从该数据库中反映出来，然后使用由Tomcat提供支持的单个池。他认为，有很多“元数据”在网络上来回传输以维护连接池。

我的理解是，通过适当地调整以仅在不同的池之间使用尽可能多的连接（低容量应用程序获得较少的连接，高容量应用程序获得更多的连接，等等），与 池 数量相比，
池 的数量并不重要 连接 相比1个池30个连接或更正式地，在开销中的差异需要维持10个连接的3个池是微不足道的。

最初将系统划分为“一个应用程序一个数据库”设计的原因是，应用程序之间可能会有差异，并且每个系统都可以根据需要对模式进行修改。同样，它消除了系统数据渗透到其他应用程序的可能性。

不幸的是，公司中没有强有力的领导才能做出艰难的决定。尽管我的同事只是模糊地支持他的担忧，但我还是要确保我了解多个小型数据库/连接与一个大型数据库/连接池的关系。