我们有一个带有中央数据库(SQL Server)和小型客户端(K
IOSK-带有本地数据库(SQL Express))的遗留系统,它使用WPF应用程序进行写入.客户端和中央数据库之间的数据同步是使用C#,ADO.NET sql语句完成的.这会对性能造成巨大损失.目前我们拥有的客户数量是400,而且还会增加.每个客户端每天向中央数据库发送100,000条记录.

我们计划使用SQL Service Broker重新编写此同步部分

其中一个主要问题是客户端和中央DB之间的架构不同.这些表没有规范化,最糟糕的情况是大多数列使用nvarchar数据类型来存储日期时间,整数数据.

我担心使用Service Broker,因为大多数业务逻辑都是使用存储过程编写的.

我想了解一下使用这种技术是最好的还是我们需要考虑使用Message Queue创建基于REST的服务.

最佳答案 TL; DR：我建议不要在这种环境中使用Service Broker.

详细的答案

虽然Service Broker确实是一种非常轻量级和可靠的通信机制,但它的设计考虑了不同的目标.也就是说,它在静态拓扑中最有效,当管理员设置一次,然后整个系统运行多年,几乎没有变化.

根据我从您的解释中理解的情况来判断,您连接的主机网络更加动态,主机每天都在进出.这将导致支持的高维护成本,因为为了在属于不同SQL Server实例的两个Service Broker端点之间建立通信,您将需要(在许多其他方面)生成至少一对证书并交换它们的公钥参与实例之间,必须在双方的主数据库和主题数据库中部署它们.

此证书交换和部署应在Service Broker消息传递之前完成,因此您需要在服务器之间建立另一个通信通道才能进行交换.通常,这是由DBA手动完成的,因为与潜在的传输级密钥丢失相关的高安全性风险.然而,在您的环境中,人们很有可能根本无法跟上.更不用说人为错误的可能性,由于大量的重复性手工工作,这种错误会很高.

简而言之,我建议寻找易于部署和维护的东西. Change tracking可能是一个好的开始;至于运输,你有一个完整的大杂烩选择,从WCF到WebAPI(到过去几年出现的其他任何东西).