0

这是场景：

我正在处理带有存储过程的 SQL Server 数据库，该存储过程负责返回 Web 提要项目 (RSS/Atom) 的标头，我通过 Web 应用程序作为提要。

此存储过程应在由以给定间隔运行的服务代理任务调用时验证基础数据是否发生重大变化 - 在这种情况下，它将触发资源密集型活动，通过调用将获取/检索数据、格式化数据并返回 SQL 数据库的 Web 应用程序。

那里将存储标头以准备好从客户端请求 RSS 提要更新。

现在，试图将其设计为尽可能高效，我仍然有几个转折点希望得到您的建议。

我对存储过程的暂定方法是：

  1. 在内存表中收集数据，
  2. 创建一个带有随信息变化的签名列的子查询，
  3. 使用 FOR XML AUTO 将它们转换为 XML
  4. 使用 MD5 对结果进行散列（使用 HASHBYTES 或 fn_repl_hash_binary，具体取决于结果的大小）
  5. 验证哈希是否与存储在我正在存储等待提要请求的 HTML 的表中的哈希匹配。
  6. 如果哈希匹配不执行任何操作，否则继续进行更新。

第一个疑问是检查基础数据是否已更改的最佳方法。

转换为 XML 会显着增加数据 - 这会减慢散列速度 - 并且可能除了散列之外我没有使用结果：有没有更好的方法来执行检查或将所有数据打包在一起以进行散列（类似于 csv 的东西）？

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

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

或者

我可能会改为保存结果集并通过服务代理触发多个异步调用。Web 应用程序可能会检索以某种方式存储的数据，而不是再次运行获取它们的昂贵查询。

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

我可能会序列化为 XML。

但是，与重新运行查询相比，这会提供任何显着的收益吗？

4

1 回答 1

0

对于有效的缓存位，请查看查询通知。在您的情况下实现这一点的棘手之处在于您已声明“重大更改”，而查询通知将在任何更改时触发。但基本思想是您的应用程序订阅查询。当该查询的结果发生变化时，会向应用程序发送一条消息，然后它会执行程序执行的任何操作（通常是刷新缓存的数据）。

至于将数据提供给您的应用程序，业内有句谚语：“不要去借钱”。也就是说，如果提供数据的默认方法（即没有花哨格式的结果集）没有给您带来问题，请不要更改它。只有当它给你带来足够严重的头痛，你的时间最好花在那里时，才改变它。

于 2012-05-06T15:56:30.673 回答