复制数据前，先向源系统提问

客服页面只需要一个答案：这笔订单是否已付款？付款系统掌握答案。集成团队却提议把每笔付款记录复制到第二个数据库，不断维护副本，客服打开订单时再读取副本。这是一个假设的运营例子，并非所引演示中的分析用例。

复制也许必要。但先问一句：页面现在是否只需要一个获授权的答案？

一场跨云分析查询的技术演示展示了在现有数据源之间查询，而无需先在目标端建立源表的永久副本。同一演示也把连接后的结果写成表，说明远程访问与复制可以共存在一条工作流里。这是真实的产品能力，却不意味着分析查询服务适合运营中的付款状态页面，也不意味着执行期间数据完全不移动。Google Cloud 的联合查询文档说明，一些外部查询结果会暂时进入查询服务。关键区别是永久同步副本与为了回答具体问题而进行的有限读取。

先看下游系统要完成什么工作

“连接两个系统”里藏着两种请求。一种问：“源系统现在怎么说？”另一种问：“目标系统必须持有什么状态，才能稍后行动？”

对客服页面而言，限定范围的读取可以返回订单状态和观察时间。源系统仍是权威来源。如果源系统不可用，页面应明确显示当前状态不可得，或清楚标记缓存答案。第二个副本反而带来新问题：两个状态不同时该相信谁？

权威来源 当前状态

有限查询 授权读取 观察时间

下游系统 一个答案

下游系统通过获授权的有限查询向源系统要一个最新答案；查询可能处理临时数据，但不建立持久副本。

购物车召回活动不同。它可能必须在无人打开页面时自动行动，需要及时事件、同意状态，以及购买后取消已排队消息的办法。发送时实时读取也许有帮助，但按需回答一个问题并不是全部工作。

下游系统的需要	首先测试的设计	主要取舍
一个当前答案	向权威来源发起限定查询	依赖源系统访问和响应时间
变化时持续行动	事件或最小增量同步	必须处理延迟、重复和遗漏事件
历史决策证据	保留相关字段的版本快照	必须治理保留期限与访问
源系统宕机时工作	明确的缓存或副本	可能过时，需要时效规则

这是决策表，不是性能基准。它不能推导出通用的“查询还是复制”阈值。

副本建立后仍持续花费成本

首次抽取容易被低估，因为它会结束；副本却会继续存在。新字段出现、两个标识合并、权限改变，或旧事件晚于新事件抵达。此时目标系统可能握有源系统会否定的答案。

成本不只是存储，还有对账：监测延迟、重放遗漏变化、按要求删除数据，以及解释为什么某项决策采用了昨天的值。当目标必须独立持有状态时，这些工作有理由存在。若交付物只是当前答案，这些维护可能是不必要的工作。

查询也有代价。它会增加源系统负载，可能把字段暴露给另一主体，跨越网络边界，并在关键时刻失败。查询规划器处理的数据也可能多于可见结果。联合查询文档列出了执行细节，不能把远程查询当成“零数据移动”。

安全查询应有狭窄目的和狭窄结果。明确字段负责人，限制调用者权限，规定答案允许多旧、最多等待多久，以及超时时界面显示什么。让观察时间随答案一起传递。

受控副本什么时候值得维护

“本地数据界面稳定，远程故障也少。”这是严肃理由。若工作流有严格的延迟要求，或必须在源系统宕机时继续运行，受控副本可能是正确设计。

重点在“受控”。定义复制哪些字段、必须多快更新、更新停止时怎么办，以及状态过期到什么程度就不能据此行动。除了正常路径，还要测试迟到的修正。快速给出过时答案，可能比清楚显示不可得更糟。

从下游最小的问题开始。如果读取就能回答，继续让源系统做权威来源。如果行动需要本地状态，只复制该行动能够证明必要的部分。

一次小范围试验就可能解决选择，无需先建通用复制层。选一个下游确实会问的问题，写明所需新鲜度，并以真实访问控制向源系统发起授权查询。观察延迟、源系统负载和失败行为。再试可满足同一需要的最窄副本。比较的不只是响应时间，还包括修正、删除和宕机时的行为。集成规划指南提供更广的工作流背景；这次试验决定答案该放哪里。把持续维护算进去，没有哪条路天然更便宜。

连接的价值不由传输了多少行数据衡量。