在远程位置之间共享数据

Question

我目前正在估算如何在不同地理位置的办事处之间最佳地共享数据 我目前的偏好是使用SQL Server Merge Replication并拥有一个主数据库和少数订阅者。

系统还需要允许一些工作站点断开连接（在建筑工地上没有或很少连接）。

数据量不会很大，我们谈论的是在制造工厂，少数区域办事处和工作站点之间共享来自定制ERP系统的数据。

Sync Framework看起来也不错，似乎在 SQL Server 2008 中有很好的支持。

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

Answer 1

坚持使用SQL Server复制，然后决定走“构建自己的复制框架”的道路。我已经看到一些应用程序变成了可怕的混乱。

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

我也有兴趣听取人们使用同步框架的经验。

您可能希望了解微软称之为 smart clients 的内容，这是一个架构微软谈论可能具有临时网络连接的应用程序。

Answer 2

我已经用#cycnus讨论了我自己对SQLServer2005的体验。我的答案不是真实的，只是提出一些我非常感兴趣的主题的论据。

1. 我们选择“不是永远连接”的网站是实现基于Web的合并复制。数据交换比通过VPN更快（因为我们也有LAN合并复制的组合）。我将通过网络轻松获得每秒30至40行的速度（512 Down / 128 Up，共享），而我将通过LAN获得每秒5行（海外，256 Up / Down，专用）。不要问我为什么......
2. 提示很多：订阅应该是客户端类型（数据在分发之前基本上从suscriber传播到发布者）。主键应始终为GUID，原因很多exposed here，但也有复制问题：我们确信任何新创建的记录都能找到发布者，因为它的PK将是唯一的。此外，我最近有一个非收敛问题，我的一个复制（糟糕的经历，暴露here），我觉得很高兴不使用自然键，因为潜在的“自然键”列出现问题
3. 数据冲突应该基本上限于工作组织问题，其中（通常由于不好的原因）同一数据被不同地方的不同用户同时修改。通过我们的“PK是GUID规则”，我们没有出现这些特定情况的冲突。
4. 即使正在运行复制，也应该始终可以修改其数据库结构。在运行合并复制过程时，可以继续添加字段，索引和约束。我还找到了一种解决方法，可以在不重新初始化复制过程的情况下添加表（暴露here，仍然不明白为什么我对这个答案进行了投票！）