2

我目前正在估计如何在不同地理位置的办公室之间最好地共享数据。
我目前的偏好是使用SQL Server 合并复制并拥有一个主数据库和少数订阅者。

该系统还需要允许一些工作场所断开连接（建筑工地没有或很少连接）。

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

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

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

2 回答 2

1

绝对坚持使用 SQL Server 复制，然后决定走“构建自己的复制框架”的道路。我已经看到一些应用程序以这种方式变得糟糕透顶。

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

我也有兴趣听听人们对同步框架的体验。

你可能想看看微软称之为智能客户端的东西 ，这是微软为可能具有临时网络连接的应用程序谈论的一种架构。

于 2008-12-09T13:39:52.543 回答
0

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

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