推荐的数据汇总框架

Question

我们有一个应用程序将采集数据并将其存储在使用Microsoft SQL Server Compact的本地WinXP PC中。我们希望将这些数据汇总到一个完整的SQL Server中进行报告和存档。数据传输需要相当连续（即不批量处理），尽管一些延迟是可以接受的（一分钟或两个最大）。

数据是从收集器到服务器的单向推送。收集器永远不需要知道其他收集器正在做什么，主服务器永远不会将数据更新回收集器。目前的计划是为5位收藏家设计的，但它的可扩展性基本上是无界限的。

我们必须假设我们会“大部分连接”，但我们无法保证从收集器到服务器的连接。如果服务器或网络出现故障，我们仍将继续收集数据，并在服务器再次可达时将数据恢复。

理想情况下，我们希望一旦我们完成基础架构工作后，非编程工程师可以设置一个解决方案。因此，我们很好地编写了一些代码和向导，但最终用户不能假定知道编写代码的任何内容，尽管他们具有合理的计算机技术知识。

现在我们有这个两名技术候选人：

1. SQL复制
2. Microsoft同步服务

我们与第一经验不多，但我们知道，建立订阅，等在SQL Server中是痛苦的，调试它们并不好玩，所以我们试图找到一个替代方案。

我们对＃2几乎一无所知，只知道它已被建议作为获取设备数据到服务器的替代方案。

有没有人在这种情况下有这方面的经验，或者有这两种技术或者我们没有想过他们可以分享的任何东西？收集器上的SQL Compact是一个固定的要求。服务器上的SQL Server不是必需的，但由于客户已经拥有它，因此需要。

Answer 1

我结束了与选项3：都没有。相反，我们只是周期性地（用户可调，但默认为5秒）使用SqlBulkCopy class复制记录。这很有效，因为它允许我们传入一个IDataReader，因此我们使用TableDirect在本地打开表，从远程表中寻找最高的RowID，然后将读取器传递给WriteToServer类。

Answer 2

尝试同步并告诉我们它是怎么回事:) 我看到一个MSFT事件，这家伙说：“我添加了这3行代码，一切都刚刚同步...... wooohhooo”。

听起来像去找我的路。

Answer 3

复制的问题在于，当您的模式更改时，您将在每个客户端上执行手动工作以重新启动并运行复制。我没有使用Sync Services的经验，但我会问同样的问题：模式更改时会发生什么？如果您必须碰触每个客户，那可能是一个问题。

Answer 4

在完全发布之前，我已经使用了Microsoft Sync Services。我喜欢它，它看起来非常适合您的应用程序。

如果您想让自己的生活变得轻松，我建议您在要与主服务器同步的所有表上使用GUID（SQL Server uniqueidentifier）作为主键。这样可以防止碰撞，以及大量额外的编码。

一个警告：我听说Sync Services在第一个版本发布后发生了显着变化，所以我的信息可能已过时。