悖论——不打开连接就知道数据库是否有变化
我正在用 C# 编写一个应用程序，需要执行以下操作：
在不连接到数据库的情况下，我需要检查数据库中是否有一些新日志。如果有，那么我可以打开连接并检索它们。
所以我只需要知道数据库中是否有新的日志（元素）而不打开与其的连接。
服务器可以向管理员发送邮件，我可以监视邮箱的更改，但该解决方案是不可接受的。
服务器在插入新行时是否可以在磁盘上创建 *.txt 文件，其中包含文本指示新行，我可以在下载更改后检查和删除/编辑该文件？
（数据库是SQL Server 2008 R2）
这可能吗？欢迎任何/和/或其他选项来执行此操作。
提前非常感谢大家。
I am writing a application in C# that needs to do the following:
without connecting to the database I need to check if there are some new logs in database. If there are then I am allowed to open the connection and retrieve them.
So I just need to know if there are new logs (elements) in the database WITHOUT opening the connection to it.
Server can send mail to administrator and I could monitor mailbox for changes but that solution is unacceptable.
Can server on inserting new rows create *.txt file on disk with text indication new rows which I can check and delete/edit after downloading change?
(database is in SQL Server 2008 R2)
Is it even possible? Any/And/Or other options to do this are welcome.
Thank you all very much in advance.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（3）
基于OP在该问题下的以下澄清评论：
我认为合适的解决方案是业务层。
如果您构建一个托管在 IIS 中的业务层，代表使用单个数据库用户进行访问的用户（应用程序池用户或 Web 应用程序中的模拟用户）执行数据库访问，则连接池将减少连接数对数据库进行了显着的修改。
这是一篇 MSDN 文章，介绍了连接池的机制和优点非常详细。
所有客户端（包括 Web 层）都将使用 WCF 或 .Net Remoting（取决于您的 .Net 版本）连接到业务层，并且业务层将是执行数据库访问的唯一应用程序。
此方法的额外好处是您可以将所有数据库访问（包括来自 Web 客户端的访问）移至 DMZ 内部，这样就不会从 DMZ 向外直接进行数据库访问。对于您的客户来说，这可能是一个很好的卖点。
我们为非常大、非常注重安全性和性能的客户广泛使用这种机制。
更新
作为替代方案，您可以让业务层每 30 秒查询一次数据库，提取必要的信息，并将其本地存储到业务层的某种数据库（Access、Sql Server Express ， ETC）。当收到来自客户端的请求时，将从本地数据存储而不是数据库为它们提供服务。
您可以通过在 global.asax 的 Application_Start 事件中启动后台线程或添加每 30 秒过期的缓存条目并在缓存超时事件中执行工作来实现此目的。
这会将每 30 秒（或任何时间）的连接数量减少到 1 个（如果网络未修改则为 2 个）。
Based on the following clarifying comments from the OP under the question:
I think that the appropriate solution is a business layer.
If you build a business layer hosted in IIS that performs the database access on behalf of the users using a single database user for access (the application pool user or an impersonated user within the web application), then connection pooling will reduce the number of connections made to the database significantly.
Here is an MSDN article that describes the mechanics and benefits of connection pooling in great detail.
All of the clients, including the web layer, would connect to the business layer using WCF or .Net Remoting (depending on your .Net version), and the business layer would be the only application performing database access.
The added benefit of this approach is that you can move all database access (including from the web client) inside the DMZ so that there is no direct database access from the DMZ outward. This could be a good selling point for your customer.
We use this mechanism extensively for very large, very security and performance conscious customers.
Update
As an alternative, you could have the business layer query the database every 30 seconds, extract the necessary information, and store it locally to the business layer in a database of some sort (Access, Sql Server Express, etc). When requests from clients are received, they will be served from the local data store instead of the database.
You could do this by kicking off a background thread in global.asax's Application_Start event or by adding a cache entry that expires every 30 seconds and performing the work in the cache timeout event.
This will reduce the number of connections to 1 (or 2 if the web isn't modified) every 30 seconds (or whatever the time is).
尝试监视 DB 文件夹内的文件更改日期。
Try to monitor files change date inside DB folder.
如果客户端桌面应用程序不打算大规模部署，您可以使用
SqlDependency。这样您就不必经常轮询数据库，相反，如果发生变化，数据库会通知您。您还可以在使用
SqlDependency的服务器上部署一个服务，然后从桌面应用程序连接到该服务。如果这不是一个选项本文档提到了一些其他选项。
这两个可以应用于您的情况：
If the client desktop application is not going to be deployed massively you could use
SqlDependency. Then you wouldn't have to poll the database on a frequent basis, instead the database will notify you if something changes.You could also deploy a service on the server which uses
SqlDependencyand then connect to this service from your desktop applications.If that's not an option this document mentions some other options.
These two could be applied to your situation: