我们有一个带有中央数据库(SQL Server(的旧系统和小型客户端(售货亭 - local db(sql express((，该系统使用WPF应用程序写下。客户端和中央数据库之间的数据同步是使用C＃，ADO.NET SQL语句完成的。这给表演带来了巨大的损失。我们目前拥有的客户数量为400，它将增加。每个客户每天将100,000个记录发送到中央数据库。
我们计划使用 SQL服务经纪
重新编写此同步部分主要问题之一，客户端和中央数据库之间的架构不同。该表未归一化，最坏的情况是大多数列都使用nvarchar datatypes存储DateTime，Intergers数据。
我担心使用服务经纪人，因为大多数业务逻辑都是使用存储过程编写的。
我想了解使用该技术是最好的，还是我们需要考虑使用消息队列创建基于REST的服务。
tl; dr：我建议不要在这种环境中使用服务经纪。
详细答案
虽然服务经纪人确实是一种非常轻巧且可靠的沟通机制，但它的设计目标是不同的目标。也就是说，当管理员一次设置所有操作时，整个系统运行多年，几乎没有更改时，它在静态拓扑中效果最好。
。从您的解释中判断，您的互联主机网络更具动态性，主机每天都会出现。这将在您的支持上产生高维护成本，因为为了在属于不同SQL Server实例的两个服务经纪端点之间建立通信，您将需要(在许多其他方面(生成至少1对证书并交换其公共钥匙在参与实例之间，它们必须在master和双方的主题数据库中部署。
应该在服务经纪消息传递之前进行此证书交换和部署，因此您需要在服务器之间进行另一个通信渠道才能进行交换。通常，由于与潜在的运输级钥匙损失相关的高安全风险，DBA是手动进行的。但是，在您的环境中，人们很有可能无法跟上。更不用说人类错误的潜力了，由于大量重复手动工作，这将是很高的。
简而言之，我建议寻找更容易部署和维护的东西。更改跟踪可能是一个良好的开始；至于运输，您可以选择从WCF到Webapi(最近几年中出现的其他内容(。