我们在本文中对数据联合模式进行了说明，此模式是一种处理对集成临时（虚拟）视图的数据操作的方法，而此类视图中的实际数据都存储在多个不同源系统中。我们在本文中主要讨论的是 SOA 上下文中的情况。我们最后将总结何时应用数据联合模式及何时不应用此模式，并将列出重要的约束。
- 上市时间是具有优异优先级的开发目标之一，数据联合可快速提供对信息源的访问，而不需要进行长时间的信息管理基础设施变更。
- 数据联合通过允许按照数据驻留在源上的方式访问数据，从而支持与数据复制和重复相关的要求。这些要求可能是为了响应法律法规或规则对数据移动或复制的限制，如订阅数据或来自不同国家的个人信息混合存在的情况。
- 像访问单个源的数据一样实时访问分布式信息。信息可以为结构化和非结构化数据。
- 用于动态更改环境（特别是模式更改的情况）的灵活的可扩展信息集成方法：由于没有数据冗余，联合模式中的更改会减少更改对所集成系统的影响。
- 当接收到的请求数量适中，而来自多个异类互补数据源的结果大小有限时，可非常好的地利用数据联合的优势。
- 需要复杂转换来构建集成视图的场景将对响应时间造成负面影响，尤其是采用这种方法时。
- 源服务器可能在必须返回联合查询中请求的数据时受到工作负载增加的负面影响。为了将请求处理到集成视图中，联合服务器将向所集成的源发送子操作。这些子操作越复杂，其发送到源系统的频率越高，源服务器需要管理的额外工作负载也就越多。
- 导致大量过渡结果集从目标数据源移到联合服务器的情况可能带来很大的性能影响。
- 应用程序要求相对较高的集成数据可用性的情况可能不适合应用这种模式。集成数据的可用性完全依赖于过程中涉及的所有联合服务器和源服务器的可用性以及网络的可用性、容量和响应能力。
- 数据联合的很多实现具有受限的数据操作功能。很多将 SQL 作为编程语言使用，且仅支持 SQL 转换。
- 性能很大程度上依赖于供应商特定的实现在缓存功能、理解异类数据源和确定非常好的联合查询和执行路径方面所表现出来的成熟度。
- 不同信息源的读写访问（特别在对逻辑工作单元进行协调时）将受到供应商特定的支持的约束。
