使用SqlDependency与表的定期轮询（对性能的影响）

Posted 2021-04-04

在我们应用程序开发的开始，我们大量使用SqlDependency来缓存数据库结果，直到通知告诉我们的应用程序获取新副本为止。

在测试期间，我们已经注意到SqlDependency通知服务对SQL DB的性能产生了影响。我们缩减了使用SqlDependency的表的数量，并注意到性能有了很大提高。因此，我们认为我们刚刚结束使用它，因此继续前进。我们现在只有几张桌子。

稍后，我们发现我们无法缩减将建立依赖关系的用户名的安全访问级别。每个数据库我们可以有多个连接字符串（一个用于依赖关系，一个用于其他应用程序），但是对于多个数据库和数据库镜像，这很麻烦（从SQL DB管理员的角度和应用程序开发的角度来看）。

至此，我们只考虑根据以下逻辑完全摆脱SqlDependency：

1. 我们不需要“即时”通知数据已更改。如果我们在一秒钟之内知道，那就足够快了。
2. 通过一些小的重构，我们可以将其简化为1个表并每秒轮询一次该表。

有人看到这种逻辑有缺陷吗？

每秒轮询一个表会导致数据库上的负载比SqlDependency多或少吗？

有人对SqlDependency有类似的性能问题吗？

答案

我敢尝试回答您的问题。但是我不确定您是否会得到您希望得到的答案...

[我记得在上世纪90年代初期，当Borland在其数据库Interbase中推广了这一宏伟的“回调”新功能时，该功能将通过一些非常漂亮的新技术向呼叫者（Delphi）提供“通知”，其中承诺数据库可以'活性'。

此后称为'waste of time theory'。

而且我想为什么这没能解决的原因可能是，尽管DBMS的概念看起来非常有前途，但是数据库是您的层之一，您只能向上扩展而不能水平扩展。

因此，编程语言可以挽救。或者更确切地说，是面向服务的体系结构（SOA）的想法。许多人将SOA混淆为“ Webservices”，这确实是这个新概念中包含的炒作。

但是，如果您查看Fiefdom / Emissary设计模式（或重新命名为Master / Agent模式，使其听起来更酷，更专业），您会发现主要思想是对其资源（读取数据库）具有排他性控制，所有呼叫都通过一个数据适配器进行传输。

显然，这种设计对于触发器和任何回调框架都根本不起作用。

但是我认为您应该重新考虑您的整个设计。如果您通过一个“ DataLayer”（可能使用实体框架）将所有操作和所有调用集中到一个缓存机制中，那么您将不必依靠数据库将消息转发到整个食物链。

为了显示在以“数据库为中心”时事情会变得多么奇怪，这是一个非常实际的实时示例，说明如何不发送很久很久以前写给我的编码员的电子邮件，这让我印象深刻：

事实1：Sql Server可以发送电子邮件。

事实2：Asp3编码器不知道是否可以在VbScript中完成此操作或如何执行此操作。

Asp3：阅读文本框的电子邮件地址，发送到com +层

Com +：获取电子邮件地址并转发到数据层

数据层：获取电子邮件地址并转发到存储过程

Sproc：获取电子邮件地址并转发到sql函数

功能：做一些奇怪的子字符串检查电子邮件地址是否带有@。在里面。返回true或false。

Sproc：返回一个记录集，该记录集的一列和一行包含1或0

数据层：按原样返回表。

Com +：将值1或0的第一列和行转换为true或false

Asp3：如果为true，则将包含电子邮件主题和电子邮件文本的电子邮件地址发送到com +

Com +：将确切的信息发送到数据层

数据层：调用存储过程。。

Sproc：调用sql函数...

功能：使用sql server电子邮件代理发送电子邮件

如果您读得很远，我的建议是让sql server管理表，关系，索引和事务。很好。那些任务之外的所有事情，以及我确实在存储过程中包括游标的方法，都可以通过适当的代码来更好地处理。