使用SQLDependency与表的定期轮询（性能影响）
在我们的应用程序开发之初，我们非常大量地使用SQLDependency来缓存数据库结果，直到通知告诉我们的应用程序获取新副本。
在测试期间，我们注意到sql db的性能受到sqldependency通知服务的打击。 我们缩减了使用sqldependency的表的数量，并注意到性能的大幅提升。 所以，我们认为我们刚刚过度使用它，我们继续前进。 我们现在只有几张桌子。
后来我们发现我们无法缩减将建立依赖关系的用户名的安全访问级别。 我们可以为每个数据库设置多个连接字符串（一个用于依赖项，一个用于应用程序的其余部分）但是使用多个数据库和数据库镜像，这很痛苦（从sql db管理角度和应用程序开发）
在这一点上，我们只是考虑基于以下逻辑完全脱离SQLDependency：
- 我们不需要数据发生变化的“即时”通知。 如果我们在1秒钟内知道，那就足够快了。
- 通过一些轻微的重新分解，我们可以将其降低到只有1个表并每秒轮询该表一次。
有没有人看到这个逻辑的缺陷？
每秒轮询一个表会导致数据库上的负载多于或少于SQLDependency吗？
是否有人与SQLDependency有类似的性能问题？
我敢尝试回答你的问题。 但我不确定你会得到你希望得到的答案……
我记得早在90年代早期，当Borland在他们的数据库Interbase中推广这个“回调”的新function时，它会通过一些非常漂亮的新技术给出调用者（Delphi）’通知’，其中承诺数据库可能是’活跃的”。
这后来被称为“ 浪费时间理论 ”。
而且我想为什么这从未采用过，或许是因为DBMS的概念看起来非常有前景，数据库是你的层级之一，你只能扩展而不是横向扩展。
所以编程语言来拯救。 或者更确切地说是面向服务的体系结构（SOA）的概念。 许多人将SOA混淆为’Webservices’，这确实是这个新概念中的一个包含的炒作。
但是如果你看看Fiefdom / Emissary设计模式（或者重命名的Master / Agent模式使它听起来更酷和专业），你会发现主要的想法是对其资源（读取数据库）和所有调用进行独占控制。正在通过一个数据适配器进行流动。
显然，这样的设计根本不适用于触发器或任何回调框架。
但我认为你应该重新考虑你的整个设计。 如果您通过单个“DataLayer”汇集所有操作和所有调用，可能使用entity framework，也许最重要的是使用缓存机制，您不必依赖数据库将消息转发回食物链。
为了展示在以“以数据库为中心”的过程中可以获得多么奇怪的事情，这里是一个极端实际的例子，说明如何不发送电子邮件，很久很久以前写的，编码器我没有那么深刻印象：
事实1：Sql Server可以发送电子邮件。
事实2：Asp3编码器不知道是否或如何在VbScript中完成此操作。
Asp3：读取文本框电子邮件地址，发送到com +层
Com +：接收电子邮件地址并转发到数据层
Datalayer：获取电子邮件地址并转发到存储过程
Sproc：接收电子邮件地址并转发到sql函数
function：做一些奇怪的子串事件来检查email-adress是否有@。 在里面。 返回true或false。
Sproc：返回一个包含一列和一行包含1或0的记录集
Datalayer：按原样返回表。
Com +：将值为1或0的第一列和第一行转换为true或false
Asp3：如果是，请将带有电子邮件主题和电子邮件文本的电子邮件地址发送到com +
Com +：将确切的信息发送给datalayer
Datalayer：调用存储过程..
Sproc：调用sql函数…
function：使用sql server email agent发送邮件
如果你读到这一点，我的建议是让sql server管理表，关系，索引和事务。 这非常好。 任何超出这些任务的东西，以及我在存储过程中包含游标的东西，都可以通过适当的代码得到更好的处理。