在远程地点之间共享数据

Question

我目前正在评估如何最好地在不同地理位置的办事处之间共享数据。

我目前的首选是使用Server合并复制，并拥有一个主数据库和少数订户。

该系统还需要允许几个工作地点断开工作(建筑工地上没有或很少连接)。

数据量不会很大，我们说的是在制造工厂、几个区域办事处和工作地点之间共享来自自定义ERP系统的数据。

同步框架看起来也不错，而且在Server 2008中似乎有很好的支持。

1. 我还应该调查其他哪些经过验证的系统来满足这些需求呢？
2. 对于那些在类似环境中分享数据有经验的人，你有什么特别的建议和建议吗？
3. 处理数据冲突对您来说有多困难？

Answer 1

一定要坚持Server复制，然后决定沿着“构建自己的复制框架”的路径前进。我见过一些应用程序会变成可怕的混乱。

我已经在断开连接的模型中设置了快照复制环境，但是远程站点是只读的。他们用最少的问题做得很好。

我还想听听人们对同步框架的体验。

您可能想看看微软所谓的http://msdn.microsoft.com/en-au/library/aa480482.aspx，这是微软为可能具有临时网络连接性的应用程序而谈论的一种体系结构。

Answer 2

我已经与#cycnus讨论了我自己的SQLServer2005经验。我的答案不是真实的，只是一些争论来启动一个我非常感兴趣的主题。

1. 我们对于“不总是连接的”站点的选择是实现基于web的合并复制。数据交换碰巧比通过VPN更快(因为我们还有局域网合并复制的组合)。我将很容易地获得30到40行每秒通过web (512 Down/128向上，共享)，而我将获得5行每秒通过局域网(海外，256上/下，专用)。别问我为什么..。
2. 提示很多:订阅应该是客户端类型的(在分发之前，数据基本上是从订阅者到发行者)。主键应该始终是GUID，因为许多原因都是暴露在这里，但也存在复制问题:那么，我们可以确定，任何新创建的记录都能够找到到发行者的途径，因为它的PK将是唯一的。此外，我最近遇到了一个不收敛的问题，我的一个复制(糟糕的经验，公开的这里)，在那里我感到很高兴不使用自然键，因为问题发生在潜在的“自然键”列。
3. 然后，数据冲突应该基本上局限于工作组织问题，在这种情况下(通常是出于不好的原因)相同的数据由不同地方的不同用户同时修改。用我们的"PK是GUID规则“，我们没有冲突走出这些具体的情况。
4. 一个人应该总是有可能修改它的数据库结构，即使复制正在运行。在运行合并复制进程时，可以继续添加字段、索引和约束。我还找到了在不重新初始化复制过程的情况下添加表的解决办法(公开的这里，仍然不明白为什么对这个答案投了反对票！)