我有一个归档过程,基本上在设定的天数后删除归档记录。是写一个预定的 SQL 作业还是一个 Windows 服务来完成删除更好?数据库是mssql2005。
更新:
谈到下面的一些答案,这个问题是关于内部应用程序而不是分布式产品。
我有一个归档过程,基本上在设定的天数后删除归档记录。是写一个预定的 SQL 作业还是一个 Windows 服务来完成删除更好?数据库是mssql2005。
谈到下面的一些答案,这个问题是关于内部应用程序而不是分布式产品。
这取决于你想要完成什么。您想将已删除的档案存储在某处吗?记录更改?SQL 作业应该执行得更好,因为它直接在数据库中运行,但更容易让服务访问数据库之外的资源。所以这取决于你想做什么,,,
我认为计划的 SQL 作业将是一个更安全的解决方案,因为如果将数据库迁移到新机器,进行迁移的人可能会忘记涉及 Windows 服务并忘记在新服务器上启动/安装它。
过去,我们运行过许多 SQL 作业。然而,最近,我们开始从 .Net 代码调用这些进程,因为客户端应用程序从 Windows 调度任务运行,原因有两个:
请注意,无论您如何操作,对于此任务,您都不需要服务。服务整天都在运行,并且整天都会消耗一些服务器的内存。
在此,您有一个需要运行的任务,并且每天运行一次。因此,您要么想要 SQL Server 中的作业,要么想要 Joel 描述的按计划设置执行然后从服务器内存空间卸载的应用程序(控制台或 winforms)。
这是给您/内部的,还是您分发的产品的这一部分。
如果在内部,我会说 SQL 工作。这也只是另一项服务。
如果它是您分发的产品的一部分,我会考虑安装和支持的方式。
To follow on Corey's point, if this is externally distributed, will you need to support SQL Express? If not, I'd go with the SQL job directly. Otherwise, you'll have to get more creative as SQL Express does not have the SQL Agent that comes with the full versions of SQL 2005 (as well as MSDE). Without the SQL Agent, you'll need another way to automatically fire the job. It could be a windows service, a scheduled task (calling a .NET app, powershell script, VBscript, etc.), or you could try to implement some trigger in SQL Server directly.