我开始设计一个新的实验室测试数据管理系统，有很多(大约 30 个)测试站。
系统必须能够在网络中断的情况下离线收集数据。
每个站都会保留测试结构(规范、实体类型、业务规则/工作流等)的最新、只读副本，但不会保留测试数据。如果找不到服务器，则将实际测试数据存储在本地。
需要某种同步来为网络中断做准备。同步将拉取更新的测试结构。另一个同步将推送未保存的测试数据。
您建议我如何实现这一目标？有什么注意事项吗？
想法/想法:
- 在每台机器上安装 SQL Server 并编写脚本来同步服务器和客户端(看起来很昂贵而且有点矫枉过正)。
- 使用同步脚本将数据的本地副本保存在应用程序定义的原始数据文件中。
- SQL Server 中是否有任何内置功能可以让客户端能够离线收集数据？
- 将所有数据保存在本地，然后单击“传输”按钮将数据推送到网络。
环境:Windows Server 2008 上运行的 MS SQL Server
最佳答案
使用本地 SQL Express 实例并通过 Service Broker 推送数据。参见 High Volume Contiguos Real Time Audit and ETL从价格、性能和可靠性等多个角度解释为什么这比复制更好。
对于 Replication，您需要在所有外围节点上获得比 SQL Express 更高的许可(因为 Express 只能是复制拓扑中的订阅者)。使用 SSB 推送数据允许在外围使用 SQL Express 实例，并且只需要一个中央非快速许可服务器。这意味着您可以轻松地将解决方案部署到数十个工作站上，而无需担心 SQL Server 许可成本。
另一个优势是性能和吞吐量。 SSB 旨在处理成百上千个通信中的对等点，并设计有复杂的分层流量控制，能够在出现网络故障时处理数千个目的地的重试(我知道这一切，因为我是 SSB 的成员团队)。相比之下，复制使用 TDS 协议(protocol)进行数据交换，它依赖于 SQL Agent 作业并以简单的方式处理网络中断，这可能导致许多循环在重试时被烧毁，使事情在本来就很糟糕的时候变得更糟。总的来说，SSB 可以处理大型部署(我知道超过 1500 台服务器的部署，MySpace 已经公开了他们的 deployment of +500 servers，它依赖 SSB 来交换数据。总的来说，在大规模情况下，SSB 在任何方面都优于复制。
我还认为基于消息而不是表行复制的解决方案更适合问题的描述:将结果推送到中央服务器。
一个缺点(而且不是一个小缺点)是最初部署 SSB 所需的陡峭学习曲线。诀窍在那里但很难找到，而且 SSB 缺乏像复制监视器这样的完善工具，这些工具使部署简单的复制拓扑成为一项直接的工作。另一方面，SSB 在升级部署时具有很大优势，如 2005/2008/2008R2 versions are perfectly compatible .
关于sql-server - 离线存储一些 SQL Server 数据，我们在Stack Overflow上找到一个类似的问题： https://stackoverflow.com/questions/3453613/