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

Question

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

在测试期间，我们注意到 SQL DB 的性能受到 SqlDependency 通知服务的影响。我们缩减了使用 SqlDependency 的表的数量，并注意到性能有了很大的提高。所以，我们认为我们已经用完了它，我们继续前进。我们现在只剩下几张桌子了。

后来，我们发现我们无法缩减将建立依赖关系的用户名的安全访问级别。我们可以为每个 DB 设置多个连接字符串（一个用于依赖项，一个用于应用程序的其余部分），但是对于多个 DB 和 DB 镜像，这是一种痛苦（从 SQL DB 管理员和应用程序开发的角度来看）。

此时，我们只是考虑完全基于以下逻辑摆脱 SqlDependency：

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

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

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

有人遇到过类似的 SqlDependency 性能问题吗？

Answer 1

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

我记得在 90 年代初期，Borland 在他们的数据库 Interbase 中推广了“回调”这一宏伟的新功能，该功能将通过一些非常漂亮的新技术向调用者（Delphi）提供“通知”，其中承诺数据库可以积极点'。

这后来被称为“waste of time theory”。

我猜为什么这从未发生过，也许是因为虽然 DBMS 的概念看起来非常有前途，但数据库是您的层之一，您只能扩展而不是水平扩展。

所以编程语言来拯救。或者更确切地说，是面向服务架构 (SOA) 的理念。许多人将 SOA 与“Web 服务”混为一谈，这确实是这个新概念中包含的炒作。

但是，如果您查看 Fiefdom/Emissary 设计模式（或重命名 Master/Agent 模式以使其听起来更酷更专业），您会发现其主要思想是对其资源拥有独占控制权（读取数据库）和所有呼叫都通过一个单一的数据适配器汇集。

显然，这样的设计根本不适用于触发器或任何回调框架。

但我认为你应该重新考虑你的整个设计。如果您通过单个“DataLayer”汇集所有操作和所有调用，可能使用实体框架，并且可能在缓存机制之上，您将不必依赖数据库将消息转发回食物链。

为了说明“以数据库为中心”时事情会变得多么奇怪，这里有一个极端的实际例子，说明如何不发送电子邮件，很久以前写的，由一个编码器写给我，我没有那么深刻的印象与：

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

事实 2：Asp3 编码器不知道在 VbScript 中是否或如何做到这一点。

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

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

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

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

function: 做一些奇怪的子字符串来检查 email-adress 是否有 @ 。在里面。返回真或假。

Sproc：返回一个记录集，其中一列一行包含 1 或 0

Datalayer：按原样返回表。

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

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

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

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

Sproc：调用一个 sql 函数...

功能：使用sql server email agent发送邮件

如果你读到这里，我的建议是让 sql server 管理表、关系、索引和事务。它非常擅长这一点。除了这些任务之外，我确实在存储过程中包含了游标，最好通过适当的代码来处理。