Sql server 如何有效地检查结果集是否已更改，并将其提供给web应用程序进行联合

以下是场景：

我正在使用一个存储过程处理一个SQL Server数据库，该存储过程负责返回通过Web应用程序作为提要的Web提要项RSS/Atom的头

当以给定间隔运行的service broker任务调用此存储过程时，应验证基础数据中是否有重大更改-在这种情况下，它将通过调用将获取/检索数据的web应用程序来触发格式化提要项标头的资源密集型活动，格式化它们并返回SQL数据库

在那里，报头将被存储，以备客户端请求RSS提要更新

现在，为了使这个设计尽可能的高效，我还有几个转折点想听听你们的建议

我对存储过程的初步做法是：

在内存表中收集数据， 创建一个子查询，其中的签名列随信息的变化而变化， 使用FOR XML AUTO将它们转换为XML 根据结果的大小，使用带有HASHBYTES或fn_repl_hash_binary的MD5对结果进行哈希 验证散列是否与存储在表中的散列匹配，在表中我存储等待提要请求的HTML。 如果哈希匹配不执行任何操作，则继续更新。 第一个疑问是检查基础数据是否已更改的最佳方法

转换为XML会显著增加数据量，这会减慢散列运算的速度，而且我可能不会使用散列运算以外的结果：有没有更好的方法来执行检查或将所有数据打包在一起以进行类似csv的散列运算

查询正在合并和聚合来自多个表的数据，因此不依赖于表时间戳，因为它们的更改不一定与结果集中的更改相关

第二点是：将数据提供给webapp进行重新格式化的最佳方式是什么？ -我可能会通过CLR函数将数据推送到web应用程序以格式化数据，但这是同步的，对于多个提要项，这将产生不可持续的延迟

或

我可能会保存结果集，并通过ServiceBroker触发多个异步调用。web应用程序可能会检索以某种方式存储的数据，而不是再次运行获取这些数据的昂贵查询

由于根据提要项类别的不同，我有不同的格式，所以我不能使用相同的表格式——因此存储到表中会很困难

我可以将其序列化为XML

---

但是，与重新运行查询相比，这会带来显著的好处吗？

对于高效缓存位，请查看。在您的案例中实现这一点的技巧在于您已经声明了重大更改，而查询通知将在任何更改时触发。但基本思想是应用程序订阅查询。当该查询的结果发生变化时，会向应用程序发送一条消息，应用程序会执行其编程所执行的任何操作，通常会刷新缓存数据

---

至于将数据提供给你的应用程序，业内有一句话：不要自找麻烦。也就是说，如果服务数据的默认方法，即不带花哨格式的结果集没有给您带来问题，请不要更改它。只有当它给您带来了足够大的麻烦，您的时间最好花在那里时才更改它。

Ben，如果我得到了正确的答案，在这种情况下，查询通知将有助于通知Web应用程序底层数据已更改，提要头需要重建。但SQL Server仍然必须检查结果集是否已更改，并将消息发布到代理队列中以获得通知。这对我没有多大帮助-我可以使用由现有CLR dll管理的HttpWebRequest通知Web应用程序触发MVC操作的相同情况-重点是有效地定义某些内容是否已更改，以便必须发送通知。我认为这比您所透露的效率要高一点。硬币的另一面是：你的更新需要多及时？我订阅了许多RSS提要，每天只更新几次，即使在RSS更新之间发布了许多文章。没关系。嗯，是的，我看了一下，听起来很有趣。我会记住，web开发的其他部分调试代理程序是很棘手的，我不确定这对web应用程序的这个特定问题如何起作用，它可以决定自己睡觉-。只是为了避免含糊不清：我所说的重大更改是指影响专栏的任何更改，在用于生成标头的数据集中（例如，它为用户带来不同的信息），“lastDataCheckTime”信息显然不会被视为重大更改