以下是该方案：
我正在使用存储过程处理SQL Server数据库，该存储过程负责返回Web Feed项目的标头（RSS / Atom）我通过Web应用程序作为提要。
当以给定间隔运行的服务代理任务调用此存储过程时，应验证基础数据是否发生了重大更改 - 在这种情况下，它将触发格式化源项的资源密集型活动通过调用Web应用程序来获取标题，该应用程序将获取/检索数据，格式化它们并返回到SQL数据库。
将存储标题，以便从客户端请求RSS feed更新。
现在，试图将其设计为尽可能高效，我仍然有一些转折点，我想得到你的建议。
我对存储过程的初步尝试是：
第一个疑问是检查基础数据是否已更改的最佳方式。
转换为XML会显着增加数据 - 这会减慢散列 - 并且我可能不会使用除散列之外的结果：是否有更好的方法来执行检查或将所有数据打包在一起进行散列（某些内容csv-等）？
查询正在合并和聚合来自多个表的数据，因此不会依赖表时间戳，因为它们的更改不一定与结果集中的更改相关
第二点是：将数据提供给webapp进行重新格式化的最佳方式是什么？ - 我可能会通过CLR函数将数据推送到Web应用程序以获取格式化数据（但这是同步的，对于多个Feed项会产生不可持续的延迟）
或
我可能改为保存结果集，并通过服务代理触发多个异步调用。 Web应用程序可能会以某种方式检索存储的数据，而不是再次运行获得它们的昂贵查询。
由于我根据Feed项目类型有不同的格式，因此无法使用相同的表格格式 - 因此存储到表格会很困难。
我可能会序列化为XML。
但与重新运行查询相比，这是否会带来任何显着的收益？
答案 0 :(得分：0)
要获得高效的缓存位，请查看query notifications。在您的情况下实现这一点的棘手问题是您已声明“重大更改”，而查询通知将触发任何更改。但基本思想是您的应用程序订阅查询。当该查询的结果发生变化时，会向应用程序发送一条消息，它会执行任何编程操作（通常刷新缓存数据）。
至于向您的应用程序提供数据，业务中有一句话：“不要去借钱”。也就是说，如果提供数据的默认方法（即没有花式格式化的结果集）不会导致您出现问题，请不要更改它。只有当它引起你足够的头痛时才改变它，以便你最好在那里度过。