现有流程会更改表中预订记录的状态字段，以响应用户输入。
我有另一个进程要编写，它将异步运行具有特定状态的记录。它将读取表记录，执行一些操作（包括调用第三方 Web 服务），并更新记录的状态字段以指示处理已完成（或 In Error，带有错误计数）。
这个操作听起来很像队列。在这种情况下，与 SQL 表相比，使用 MSMQ 的好处和权衡是什么？为什么我应该选择其中一个？
是我们的软件在表中添加和更新记录。
这是一个将执行异步处理的新工作（Windows 服务）。这需要“永远在线”。
【问题讨论】：
标签： sql msmq message-queue
有几个原因，在 Fog Creek 论坛上讨论过：http://discuss.fogcreek.com/joelonsoftware5/default.asp?cmd=show&ixPost=173704&ixReplies=5
主要的好处是，当计算机之间存在间歇性连接（使用本地计算机上的存储和转发机制）时，仍然可以使用 MSMQ。就应用程序而言，它会将消息传递给 MSMQ，即使 MSMQ 稍后可能会传递消息。
只有在可以连接到数据库的情况下，才能向表中插入记录。
当需要工作流方法时，表格方法更好，并且流程将经过各个阶段，并且这些阶段需要在数据库中持久化。
【讨论】：
如果创建预订记录的速度很低，我会让第二个过程定期检查表中是否有新预订。
除非您已经在使用 MSMQ，否则引入它只是为您提供了一个额外的平台组件来支持。
如果数据库负载很重，或者您在两个进程读取和写入预订表的同一区域时遇到大量锁争用，那么请考虑引入 MSMQ。
【讨论】：
我也喜欢le dorfier 在previous discussion 中的这个回答：
我先使用表，然后重构 当（和 如果）有原因 - 这是微不足道的 如果你的设计是合理的。
谢谢大家，所有的答案。最有帮助。
【讨论】：
使用 MSMQ，您还可以通过将队列的位置更改到另一台机器而不是数据库服务器，轻松地将工作卸载到另一台服务器。
顺便说一句，从 SQL Server 2005 开始，数据库中内置了队列。它称为 SQL 服务器服务代理。 见：http://msdn.microsoft.com/en-us/library/ms345108.aspx
【讨论】：
【讨论】：
如果您有 MSMQ 专业知识，这是一个不错的选择。如果您了解数据库但不了解 MSMQ，请问自己是否想成为另一项技术的专家；您的申请是否是关键申请；当出现问题时，您更愿意调试它。
【讨论】：
我最近一直在自己调查这个问题，所以想提一下我的发现。与您的应用程序相比，数据库的位置是决定哪个选项更快的重要因素。
我测试了插入插入 100 个数据库条目所花费的时间与将完全相同的数据记录到本地 MSMQ 消息中的时间。然后，我对多次执行此测试的结果取平均值。
我发现当数据库在本地网络上时，插入一行比登录到 MSMQ 快 4 倍。
当通过良好的互联网连接访问数据库时，向数据库中插入一行比登录到 MSMQ 慢 6 倍。
所以：
本地数据库 - DB 更快，否则 MSMQ 更快。
【讨论】：
如果您将服务实现为排队的 COM+ 组件并从客户端应用程序进行排队的函数调用，可能会更容易，而不是进行原始 MSMQ 调用。最后异步服务还是在后台使用MSMQ，但是你的代码会更清晰，更容易使用。
【讨论】：
我自己可能会选择 MSMQ 或 ActiveMQ。我会建议（假设您正在考虑使用 MSMQ，您正在使用带有 MS 技术的 windows）查看 WCF，或者如果您使用的是 MS-SQL 2005+，则有一个触发器可以调用 .net 代码来运行您的处理。
【讨论】：
Service Broker 是在 SQL 2005 中引入的，它旨在非常快速地处理消息，因为该过程相对简单（我相信它的根源在于触发器）。如果您担心可伸缩性，他们在 SQL 2008 中发布了一个独立的处理可执行文件，以将处理与 SQL Server 分开（在标准 Service Broker 中，一切都由 SQL Server 实例控制）。
我肯定会考虑在 MSMQ 上使用 Service Broker，但这取决于您的 SQL 开发/DBA 资源及其知识。
【讨论】：
除了米奇的回答，还有一些其他的场景： 1.你的每条消息都有自己的触发动作的截止日期，这也可以通过MQ来完成，但在这种情况下，我更喜欢将它存储到db中，因为它更可控； 2.订阅者需要过滤消息然后处理其中的一部分，这也可以通过LINQ完成，取决于过滤器的复杂程度，db方法更好，因为我可以使用linq to EF轻松进行复杂查询； 3. 对于部署，我想要完全自动化的部署过程，这样 DB 对我来说是一个更好的选择。我不是手动配置的忠实粉丝。
【讨论】：