在工作中，我们在集中式SQL服务器中有几个数据库应用程序。每当一个应用程序需要处理来自另一个应用程序的数据时，它只是查询它或通过数据库更新它。我相信这是“企业集成模式”一书（Hohpe＆amp; Woolf）中描述的“共享数据库”模式。
这些跨数据库依赖性正在给我们带来许多令人头疼的问题。现在最大的问题是我们在SQL服务器上遇到性能问题，并且由于跨数据库依赖性而无法扩展。我认为我们应该做的是从共享数据库模式转向EIP手册中描述的消息传递系统。每个应用程序都将负责所有自己的数据，而其他想要访问该数据的应用程序将通过服务（在消息传递总线上？）来获取它。
答案 0 :(得分：7)
我建议进行3阶段过渡。
另外，假设您有3个申请; A，B和C.
您还可以将其视为3个单独的过渡：
申请A
申请B
申请C
在此过程中，结果与阶段2结束时的结果相同，阶段3可以继续进行。不同之处在于，专注于某种重构还是专注于应用程序是否更有效率。
答案 1 :(得分：1)
消息传递肯定是更优雅的方式之一。但是，它还需要一些工作，并且随着每个数据库的更改而不得不随时间变化。我们采用“更简单”的方法，只需让每个应用程序知道如何登录到其他数据库，然后从那里查询每个数据库。我们发现大多数跨数据库查询非常简单，因此不会在第二个应用程序中构成实质性的代码库。选择查询有一些重复，但它的工作量比消息传递系统少。
这一切都取决于你将推动和拉动数据的程度。如果它是实质性的，那么消息传递是最好的方式。如果它是最小的，那么也许可以通过一个简单的新连接到另一个数据库。
答案 2 :(得分：1)
我还会考虑应用程序如何使用数据库。通常，数据库（设计和实现）应分为两类：事务（OLTP）或报告（OLAP）。
设计良好（并实现）的事务数据库应该在典型的业务线应用程序场景中提供出色的性能;同样，设计良好（并实施）的报告数据库在查询大量复杂数据时应提供出色的性能。
另一个重要区别是“实时”和“近实时”之间的差异。
让我们假设您的各种应用程序需要执行事务（实时）操作和一些当前/旧数据的报告;您需要两个数据存储：一个专门用于支持应用程序“实时”操作的操作速度的事务存储，另一个包含纯粹用于报告的“历史”数据。
然后，要弄清楚您需要在事务数据存储中保留多少数据，以及何时/如何将其移动到报告数据存储。