当数据更新时，如何在数据库之间进行实时数据传输？
这是我的高层次问题：
我们有两个业务应用程序。 App1输入并存储大量数据。 当 App1 中的任何相关数据发生更改时，我们需要将数据从 App1 传输到 App2。 本质上我们希望App2中的数据从App1同步，只不过App2包含数据的子集。
App1 使用 SQL Server 2000 数据库。
App2 使用 SQL Server 2005 数据库。
因此，举例来说，如果用户正在使用 App1 并且更新了一些数据，则需要将该数据保存到 App1 数据库，然后尽可能实时地发送到 App2 数据库。
寻找一些不会让任何一个系统屈服的好主意。
Here's my problem at a high level:
We have two business applications. App1 inputs and stores a large set of data. We need something that will transfer data from App1 to App2 whenever any relevent data in App1 has changed. Essentially we want the data in App2 to be synchronized from App1, except that App2 contains a subset of the data.
App1 uses a SQL Server 2000 database.
App2 uses a SQL Server 2005 database.
So, for example, if a user is using App1 and they update some data, that data needs to get saved to the App1 database and then sent to the App2 database, as realtime as possible.
Looking for some good ideas that won't bring either system to its knees.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（3）
您是否考虑过复制？
Have you considered replication?
想必您可以将其表述为“当系统 A 中发生感兴趣的事件时，调用操作 B 来异步（即解耦）更新系统 C”。
听起来像是一个消息队列——无论是形式上的还是数据库表中的。
有些人可能会认为“触发”，但那里存在致命的同步依赖性。 但触发器可以填充队列。
Presumably you could state this as "When an event of interest occurs in System A, invoke Action B to asynchronously (i.e. decoupled) update System C."
Sounds like a message queue - either formally, or in a database table.
Some might think "trigger", but there's a deadly synchronous dependency there. But a trigger could feed the queue.
它们位于不同的物理位置吗？ 为什么不能使用单个数据库并只允许 app2 访问允许访问的数据子集？
Are they in different physical locations? Why can't you use a single database and only allow app2 to access the subset of data that it is allowed to?