代码之家  ›  专栏  ›  技术社区  ›  Kobojunkie

C#/SQL数据库侦听器

  •  14
  • Kobojunkie  · 技术社区  · 15 年前

    我需要连续监视数据库行以检查更改(更新)。如果其他来源有一些更改或更新,则应在我的应用程序上触发事件(我使用的是WCF)。有没有办法持续监听数据库行的更改?

    6 回复  |  直到 6 年前
        1
  •  5
  •   gnz    15 年前

    为了简化部署,我创建了一个CLR SP,其中包含一个名为 SendMessage 这只是将消息推送到消息队列中,并使用AFTER-INSERT触发器(普通触发器,而不是CLR触发器)将其绑定到我的表中。

    在本例中,性能是我主要关心的问题,但我已经对其进行了压力测试,结果大大超出了我的预期。与SQLServerServiceBroker相比,它是一个非常易于部署的解决方案。CLR SP中的代码也非常简单。

        2
  •  9
  •   Mitch Wheat    15 年前

    可以在相应的表上使用更新后触发器将项添加到 SQL Server Service Broker 队列然后将排队通知发送到web服务。

    另一张海报提到了SqlDependency,我也想过要提到它,但MSDN文档有点奇怪,因为它提供了一个windows客户端示例,但也提供了以下建议:

    在ASP.NET或中间层服务中 那里有一个相对较小的 具有依赖关系的服务器数 针对数据库激活。是的 不是为在客户端中使用而设计的 应用程序,其中数百个或 数千台客户端计算机将 将SqlDependency对象设置为

    Ref .

        3
  •  2
  •   Paul Sasik    15 年前

    “连续”监测可能意味着每隔几小时、几分钟、几秒钟甚至几毫秒进行一次。此解决方案可能不适用于毫秒更新:但如果您每分钟只需“监视”一个表几次,您只需让一个外部进程检查一个表的更新即可(如果存在DateTime列),则可以处理更改的行或新添加的行,并执行所需的任何通知。所以你不会去听变化,你会去检查它们。以这种方式进行检查的一个好处是,如果在给定的时间段内更新了很多行,那么您就不会冒性能下降的风险,因为您可以将它们聚集在一起(而不是单独响应每个更改)

        4
  •  2
  •   Johannes Rudolph    15 年前

    我思考了CLR函数的概念 该服务在成功完成后恢复 从中插入/更新/删除数据 桌子。这样好吗 情况如何?

    也许这不是个好主意,但我想这总比下地狱要好。

    我假设您的问题是,在每次数据修改之后,您都想做些什么,比如,重新计算一些值或其他什么。让数据库负责这不是一个好主意,因为它可能会对性能产生严重影响。

    更好的解决方案是将检测数据修改的责任从数据库转移到应用程序。这实际上可以非常容易和有效地实现。

    为了检测修改,您的WCF服务/监视应用程序在给定的时间间隔内构建一个本地字典(最好是哈希表),其中包含主键/时间戳对。使用数据库中的覆盖率索引,此操作应该非常快。下一步是比较两本字典,瞧,你看。

    不过,这种方法有一些警告。其中一个是每个表的记录总数,另一个是更新频率(如果太低,则无效),还有一个精确点是在修改/插入之前是否需要访问数据。

        5
  •  1
  •   Pradeep    15 年前

    为什么不使用SQL Server通知服务?我想那正是你要找的东西。浏览notification services的文档,看看是否符合您的要求。

        6
  •  0
  •   Paul    15 年前

    我认为这里有一些很棒的想法;从可伸缩性的角度来看,我认为外部化检查(例如Paul Sasik的答案)可能是迄今为止最好的一个(对他来说是1)。

    如果出于某种原因,您不想将检查外部化,那么另一种选择是使用HttpCache来存储一个观察者和一个回调。

    简言之,当您将记录放入要查看的DB中时,您还可以将其添加到缓存中(使用.add方法),并对其设置SqlCacheDependency,以及在调用依赖项并从缓存中弹出项时,对您想要调用的任何逻辑进行回调。

    推荐文章