设计归档数据的流程 (SQL Server 2005)

Posted 2023-03-06

【中文标题】设计归档数据的流程 (SQL Server 2005)

【英文标题】：Design a process to archive data (SQL Server 2005)

【发布时间】：2011-11-29 15:22:44

【问题描述】：

我们正在设计一个流程，以根据日期、状态等不同标准归档一组记录...

简化的表集： Claim, ClaimDetails, StatusHistory（跟踪声明状态的变化）、Comments & Files

环境： SQL Server 2005，ASP.Net MVC (.NET Framework v3.5 SP1)

Claim 是主要实体，它在提到的子表中有子行。有些有详细信息，有些用于跟踪更改。最终，根据某些标准，Claim 变为“准备存档”，如上所述。简而言之，存档的Claims 将从数据库中识别出来，并在网络应用程序中进行不同的处理。

这是一个最简单的版本：（顶视图）

创建一个在数据库中标记Claim“已归档”的脚本。 存档行及其子行可以保留在同一个表中（设置一个标志），也可以移动到另一个表中，该表将是原始表的副本。 在网络应用中，我们将让用户根据存档状态过滤Claims。 将来可能需要“取消归档”Claim。

我需要知道什么？

我们需要尽可能地简单易行，并且要灵活地适应未来的变化 - 请提出一种方法。

及时调度的 SQL 脚本是这种情况下的最佳选择吗？

我应该考虑使用单独的表还是只为每个表添加一个“存档”标志？

对于所选方法的性能考虑 - 如果我们计划拥有大约 10,000 个 Claims 和如果它是 100 万个会有什么不同。简而言之，请提及轻载和重载方法。

我们将物理上传的文件存储在我们的服务器上 - 我相信这可以保持原样。

注意：声明可以在所有提到的表中包含任意数量的子记录，因此它是 n 倍的。

是否有我应该参考的标准框架或模式来了解归档过程。任何示例参考文章或工具都可以帮助我了解更多信息。

【参考方案1】：

你可以找到关于这个主题的一些很好的讨论here 和this 是另一个。

将归档数据放在单独的表格中提供了更大的灵活性，例如，如果您想跟踪将声明标记为已归档的用户或归档声明的日期，或者查看声明创建后对其所做的所有更改。

【讨论】：

谢谢，但这更像是在每次编辑时维护数据库日志。一旦记录存档，我需要维护“存档”的东西，它变成只读的，因此不需要维护多个版本。此外，我们谈论的是 2-3 年时间跨度内的几百万条记录。

在每个表上都有一个存档标志是最简单的解决方案，但对于您将来可能进行的任何更改，这不是一种非常灵活的方法。您还应该考虑在您的应用程序中使用归档数据的频率。如果主动声明的访问频率高于归档声明，则为归档声明创建单独的表会提供更好的性能，因为您将查询一小组数据。