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

Question

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

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

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

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

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

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

我需要知道什么？

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

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

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

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

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

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

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

Answer 1

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

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