当数据更新时，您将如何在数据库之间进行实时数据传输？答案

【问题标题】：How would you do realtime data transfer between databases when data is updated?当数据更新时，您将如何在数据库之间进行实时数据传输？
【发布时间】：2010-09-23 02:25:59
【问题描述】：

这是我的高层次问题：

我们有两个业务应用程序。 App1 输入并存储大量数据。当 App1 中的任何相关数据发生变化时，我们需要将数据从 App1 传输到 App2 的东西。本质上，我们希望 App2 中的数据与 App1 同步，只是 App2 包含数据的子集。

App1 使用 SQL Server 2000 数据库。

App2 使用 SQL Server 2005 数据库。

因此，例如，如果用户正在使用 App1 并且他们更新了一些数据，则这些数据需要尽可能实时地保存到 App1 数据库，然后发送到 App2 数据库。

寻找一些不会让任何一个系统都崩溃的好主意。

【问题讨论】：

App2 是纯只读的吗？还是用户会对 App2 进行更改并期望这些更改传播到 App1？
App2 不会是只读的，但是返回的数据量会小很多。我猜这将是大约 100 比 1 的比率。

标签： sql-server data-transfer real-time

【解决方案1】：

你考虑过replication吗？

【讨论】：

我没有考虑过，但我会调查一下。感谢您的建议！

【解决方案2】：

大概您可以将其表述为“当系统 A 中发生感兴趣的事件时，调用操作 B 以异步（即解耦）更新系统 C。”

听起来像一个消息队列 - 无论是正式的，还是在数据库表中。

有些人可能会认为是“触发”，但那里存在致命的同步依赖。但是触发器可以提供队列。

【讨论】：

我认为你是完全正确的 - 我一直在思考观察者模式，其中 App1 的数据库是主题，而 App2 是观察者。消息队列似乎是一种显而易见的实现方式。另外，我喜欢您关于使用触发器来提供队列的建议。谢谢！

【解决方案3】：

他们是否在不同的物理位置？为什么不能使用单个数据库，只允许 app2 访问允许访问的数据子集？

【讨论】：

好问题！他们在不同的物理位置吗？是的。为什么不使用单个数据库？因为我们实际上将拥有多个 App1 应用程序（和数据库），它们的数据都将被单个 App2 应用程序组合和使用。