如果使用 RMO，我应该使用推送订阅还是拉取订阅? [英] Should I use a push or pull subscription if using RMO?

问题描述

我有一个 CRUD winform 应用程序，它使用合并复制来允许断开连接"功能.我的问题是；如果我使用 RMO 以编程方式进行所有初始化和同步(例如 HERE) 是推还是拉有关系吗?

I have a CRUD winform App that uses Merge Replication to allow "disconnected" functionality. My question is; If I am doing all initializing and synchronizing programatically with RMO (like HERE) does it matter if it is a Push or Pull?

会有什么不同?

我了解两者之间的区别(请参阅此处)但似乎如果我只通过 RMO 进行交互，差异就会变得有点模糊.如果可以的话，虽然合并复制偏爱Pull，但我想用Push让Server首当其冲，更容易管理.

I understand the differences between the two (see HERE) but it seems that if I am only interacting through RMO the differences become a little fuzzy. If I can it seems that, even though Pull is favored for Merge Replication, I would want to use Push to make the Server bear the brunt and easier management.

此外，由于我们的环境，我不需要实时"更新.在任何一种情况下，同步都会从 UI 事件中触发.

Also, due to our environment, I do not need "real-time" updates. Syncing, in either case, will be fired from a UI event.

有人有这方面的经验吗?

Does anyone have any experience with this?

谢谢！

推荐答案

我们通过 RMO 在 20 多个偶尔连接的客户端系统上使用合并复制.据我所知，你应该使用拉订阅.我不知道你是否可以让它与推送订阅一起工作，但我不建议尝试.正如您所说，客户端系统将请求同步，这符合请求订阅的定义.

We use merge replication via RMO on 20+ client systems that are occasionally connected. As far as I know, you should go with pull subscriptions. I don't know if you could make it work with push subscriptions but I don't advise trying. As you say, the client system will be requesting the sync, which fits the definition of a pull subscription.

您的第二个链接中的使用时间"部分在这种情况下的推送建议中非常明确:

The "Use When" section in your second link is pretty clear in its recommendation for push in this case:

• 数据通常会按需或按计划同步，而不是
• 该出版物有大量订阅者，和/或订阅者过多资源密集型运行所有经销商处的代理商.
• 订阅者是自主的、断开连接的和/或移动的.订阅者将决定他们何时将连接并同步更改.
• 最常用于合并复制.

这篇关于如果使用 RMO，我应该使用推送订阅还是拉取订阅?的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！