悖论——不打开连接就知道数据库是否有变化答案

【问题标题】：Paradox - know whether there is change in the database without opening a connection悖论——不打开连接就知道数据库是否有变化
【发布时间】：2012-01-29 01:35:15
【问题描述】：

我正在用 C# 编写一个需要执行以下操作的应用程序：

在不连接数据库的情况下，我需要检查数据库中是否有一些新日志。如果有，那么我可以打开连接并检索它们。

所以我只需要知道数据库中是否有新的日志（元素）而不打开与它的连接。

服务器可以向管理员发送邮件，我可以监控邮箱的更改，但该解决方案是不可接受的。

服务器能否在插入新行时在磁盘上创建 *.txt 文件，其中包含新行的文本指示，我可以在下载更改后检查和删除/编辑这些新行吗？

（数据库在 SQL Server 2008 R2 中）

有可能吗？欢迎任何/和/或其他选择。

提前非常感谢大家。

【问题讨论】：

所以我们可以适当地回答：这里避免连接的驱动是什么？数据库服务器对于简短的连接和检查相当友好。此外，哪些技术会是可以的？数据库是否需要处理外部检查？或者“更新外部标志和更新数据库”方法是否有效？
客户的愿望是驱动力。有一个 Web 应用程序每 30 秒检查一次更改并显示最新的授权。数据库正在跟踪员工授权并经常更新。现在我正在构建桌面应用程序，它与服务器有本地连接并且可以更频繁地更新，但是客户端不希望应用程序每秒打开连接，aldo 连接打开了几毫秒。技术 - C# Win Form 应用程序，SQL SERVER 2008 R2。
我正在考虑在磁盘上创建 *.txt 文件，并在数据库中插入一些文本 (1/thereischange/true)，然后使用桌面应用程序在磁盘上找到该文件 - 阅读它 -如果更改设置为真 - 打开连接 - 检索更改 - 将文件中的文本设置为假。有可能吗？

标签： c# database-connection sql-server-2008-r2 data-retrieval

【解决方案1】：

尝试监控数据库文件夹内的文件更改日期。

【讨论】：

这不是一个坏提示，因为我在这里不知道，但这需要每个使用桌面应用程序的用户访问服务器计算机上的程序文件，这不是一个选项。 *txt 文件可以存储在安全问题上没有争议的某个位置。
我可以在服务器机器上创建服务来监控 db 文件中的文件更改，然后检查该服务以获取有关更改的信息吗？
是的，您可以在数据库服务器上创建一个服务来监控数据库文件系统的变化。然后，您的客户端应用程序可以连接到此服务以接收数据库更新通知。但让我们面对现实吧：这很丑。您应该尝试说服您的客户最好的解决方案是直接连接到数据库以检查是否有更新。
我已经问了他们五次“什么 - 你确定你想要那个？！我应该怎么做？他们说 - 是的，这是标准的日志查看器功能”

【解决方案2】：

如果不打算大规模部署客户端桌面应用程序，您可以使用SqlDependency。这样您就不必频繁地轮询数据库，而是数据库会在发生变化时通知您。

您还可以在使用SqlDependency 的服务器上部署一个服务，然后从您的桌面应用程序连接到该服务。

如果这不是一个选项this document 提到了一些其他选项。

这两个可以应用于您的情况：

在被监控的表上创建一个 AFTER UPDATE 触发器，其操作使用 SQL Server Service Broker 向需要通知的实体发送消息。
使用支持更改通知机制的 Windows Server App Fabric 缓存，它基于内存中的对象缓存和您在对象中注册的回调函数。

【讨论】：

客户要求在不使用触发器的情况下完成工作，因为它们“需要大量维护”。
@Mr.100le 还有我提到的其他选项吗？
我需要探索他们的实现能力，我不能在这么短的时间内给出答案。非常感谢你，你让我从空白的街道上走了出来。

【解决方案3】：

基于问题下 OP 中的以下澄清 cmets：

有一个 Web 应用程序每 30 秒检查一次更改并显示最新的授权。数据库正在跟踪员工授权并经常更新。现在我正在构建桌面应用程序，它与服务器有本地连接并且可以更频繁地更新，但是客户端不希望应用程序每秒打开连接，aldo 连接打开了几毫秒。

我认为合适的解决方案是业务层。

如果您构建一个托管在 IIS 中的业务层，它代表使用单个数据库用户进行访问的用户（应用程序池用户或 Web 应用程序中的模拟用户）执行数据库访问，那么连接池将减少与数据库建立的连接数显着。

Here is an MSDN article 详细描述了连接池的机制和好处。

包括 Web 层在内的所有客户端都将使用 WCF 或 .Net Remoting（取决于您的 .Net 版本）连接到业务层，而业务层将是唯一执行数据库访问的应用程序。

这种方法的额外好处是，您可以将所有数据库访问（包括来自 Web 客户端的）移动到 DMZ 内，这样就不会从 DMZ 向外直接访问数据库。这对您的客户来说可能是一个很好的卖点。

我们将这种机制广泛用于非常大型、非常注重安全性和性能的客户。

更新

作为替代方案，您可以让业务层每 30 秒查询一次数据库，提取必要的信息，并将其本地存储到某种数据库（Access、Sql Server Express 等）中的业务层。当收到来自客户端的请求时，它们将从本地数据存储而不是数据库提供服务。

您可以通过在 global.asax 的 Application_Start 事件中启动后台线程或通过添加每 30 秒过期的缓存条目并在缓存超时事件中执行工作来做到这一点。

这将每 30 秒（或任何时间）将连接数减少到 1 个（如果未修改网络，则为 2 个）。

【讨论】：

尝试与数据库通信而不与数据库通信应该是朝着错误方向前进的明确指标。这是对实际问题的一个很好的回答：“我如何知道数据库何时发生更改而不会使数据库与连接过载？”
用户具有不同的访问权限，这些权限在数据库中定义，因此他们必须是不同的数据库用户。
确实“编程英雄”你得到了这两个点，它们都是我的问题的一部分 - 但是实施，业务层可能对我的客户来说是一个很大的变化，他们不愿意接受这一点。认为这应该是一些易于创建的小型解决方案，可以在几个小时内完成。
@Mr.100le：我真的不认为这是一个很大的努力。创建 Web 应用程序，添加数据库访问代码，并使用单一方法添加 WCF 服务。它不应该超过几个小时。同时，您可能还想寻找新客户。