1

我有一张记录客户联系人信息的表格。该表仅定义为“最近”联系人，我想删除超过 3 周的联系人的所有记录。

例如，该表是：

create table recent_contact {
   recent_contact_id int identity (1,1) primary key,
   contact_text nvarchar(4000),
   created datetime
}

create index createdIndex
on recent_contact (created)

对该表的所有插入都将通过只执行 INSERT 语句的存储过程发生。

我的问题是关于清理的。我想删除所有超过 3 周的项目。到目前为止，我已经想到了两种完成清理的方法。

  1. 定期（例如每 5 小时）运行一个后台数据库作业，该作业将扫描上表并删除超过 3 周的任何内容。

  2. 在insert()存储过程调用中，添加清除旧数据的逻辑。这只会增加恒定的时间开销，因为表是在 [created] 上建立索引的，并且每个项目只插入一次并且只删除一次。所以平均来说这个存储过程会做 1 次插入和 1 次删除。

// insert
insert into recent_contacts (contact_text, created)
values (@text, @createDate)

declare @threeWeeksAgo datetime
set @threeWeeksAgo = DATEADD(DAY, -21, GETDATE())

// remove old items
delete from recent_contacts 
where created < @threeWeeksAgo

在这两个选项中，我选择了选项 2)，因为我觉得这是一个更优雅的解决方案，并且不需要单独的清理工作。我的同事告诉我，这是一种不好的做法，保留政策应该始终在一个单独的工作中定期运行。即他认为选项 1) 是更好的选择。

我想知道其他人是怎么想的？一般来说，执行数据保留策略的最佳实践是什么？

4

2 回答 2

2

做1）。选项 2) 是一个错误的想法。没有理由回避周期性工作，但是有很多理由可以避免以查找陈旧条目的成本来惩罚每个插入，甚至更惩罚 INSERT 随机达到响应时间的峰值，因为这是不走运的彩票中奖者清理一些参赛作品。另一方面，安排好的工作可以安排在方便的时间。最后但并非最不重要的一点是，考虑到您的“聪明”设计需要插入才能进行维护。

随着时间的推移，您将了解到，由于索引临界点问题，数据保留期的清理实际上是一个非常棘手的问题，许多开发人员机构都为此铺平了道路。您还将发现时间序列就像按时间列的聚集索引，尤其是因为过时的数据清理问题。

于 2012-04-30T22:40:58.893 回答
2

我会选择 1) 因为：

  • 最好有一个专门的过程来清理旧数据。使用 2)，您将两个进程交织在一个例程中，并且如果（当）一个进程发生更改时，您只需修改该部分代码，而不会弄乱另一部分。
  • 类似的，如果它以某种方式破裂会发生什么？通过两个过程，如果出现问题，您可能会加倍必要的故障排除工作。
  • 如果出于某种原因（停电、节假日、淡季）没有人插入新行，会发生什么？您的数据超出了保留窗口，但仍保留在系统中。

根据代码库的大小和总数据量（我猜这非常小），这些比其他任何东西都更狡猾（除非数量随着时间的推移显着增长......）即便如此，现在使用“更安全”的策略构建良好的习惯和实践，因此如果有一天您必须使用大容量系统，您更有可能在第一次通过时生成适当健壮的代码。

于 2012-04-30T22:41:33.750 回答