什么类型的 SQL Server 复制适合我们的方案？合并还是交易？

Question

背景

在我们当前的设置中，我们在远程托管的 Web 服务器上有一个 SQL Server 2005 实例。我们还有另一个（非 MSSQL）数据库用于我们的 POS 系统，当事情（例如产品信息）发生变化时，它会自动更新 Web 服务器。这有两个问题：

1. 连接速度可能很慢，因此我们无法轻松处理代码的本地副本
2. 有时我们无法访问网络数据库（即使该站点仍然有效），这会导致 POS 系统挂起。

我正在努力的解决方案是在公司总部本地设置第二个 SQL Server 实例（2005 或 2008），将 POS 系统指向它，并使用某种形式的复制来同步它们之间的更改。但是，我不知道我们应该使用合并复制还是事务性的。

---

题

合并或事务复制会更好地为我们服务吗？

我们的要求是：

1. 在总部更新产品数据并将其以只读方式推送到网站。
2. 更新网站订单数据并推送至总部
   1. 将总部的小改动同步回网站（订单状态）
3. 当无法通信时，两端的可用性不会中断
   1. 即总部仍然可以访问和更新我们的副本，网站可以更新其，当通信恢复时，更改将同步。
4. （可选）一种简单的方法来制作 HQ 数据库副本，删除复制，用于代码测试目的。

哪一种更符合我们的要求？

Answer 1

一些想法。在我看来，如果你最终得到的是复制，你可能可以摆脱几个选择。首先要注意的是——复制不应该只在生产中配置并启用/使用，除非您有一些经验。对于更重要的工作负载和更繁忙的系统来说，这一点变得更加正确。如果复制处理不当，可能会引起头痛。我会投资于指导/培训/咨询，以帮助那些已经被错误所困扰的人走上这条道路。

就是这样说的。在我看来，您的要求似乎没有任何需要同步或合并的双向更改。看起来你有一堆事情需要朝一个方向发展。订单永远不会在本地发出，只会在网站上发出。订单状态永远不会在网站上生成，只会消耗等。

如果是这样的话 - 这对我来说听起来就像事务复制。合并更适合当您需要拥有多个可以同时进行更改和接收更改的版本时。陈旧的微软例子仍然有效——一群销售人员都使用一个本地应用程序来进行领导管理和一个大型中央服务器。他们可以在家庭办公室获得线索并获取数据，然后他们可以离线工作并同步他们的更改。使用合并时，您必须处理冲突（如果在两个地方修改相同的数据，谁会获胜？）事务性更多的是当您朝一个方向进行更改时使用事务性（但您甚至可以在这里使其双向）。

您还可以设置复制以将各种表作为文章包含或不包含在出版物中。

有几个链接可以为您提供更多信息：

事务复制概述

合并复制概述

现在，如果您有可以在每个数据上更新并且需要“合并”的数据，那么合并可能是更好的答案。当我使用复制时，我更喜欢尽可能接近事务性。它更容易管理，并且如果您不需要它，也不用担心解决冲突。

根据您的容量（如果足够低）和您的延迟（如果某些延迟时间可以接受），您可能还会考虑更具编程性或 ETL 之类的东西。也许暂存数据并批量发送。当一侧的数据发生变化时发送消息等。