我和一些同事就存储历史数据的最佳方式展开了辩论。目前，对于某些系统，我使用单独的表来存储历史数据，并为当前的活动记录保留一个原始表。所以，假设我有 FOO 表。在我的系统下，所有活动记录都将进入FOO，所有历史记录都将进入FOO_Hist。用户可以更新 FOO 中的许多不同字段，因此我想准确记录所有更新的内容。FOO_Hist 包含与 FOO 完全相同的字段，但自动递增的 HIST_ID 除外。每次更新 FOO 时，我都会在 FOO_Hist 中执行一个插入语句，类似于：insert into FOO_HIST select * from FOO where id = @id。
insert into FOO_HIST select * from FOO where id = @id
我的同事说这是一个糟糕的设计，因为出于历史原因，我不应该有一个表的精确副本，而应该将另一条记录插入到活动表中，并带有一个标志，表明它是出于历史目的。
有处理历史数据存储的标准吗？在我看来，我不想将我的活动记录与我的所有历史记录放在同一张表中，因为它可能超过一百万条记录（我认为是长期的）。
您或您的公司如何处理这个问题？
我正在使用 MS SQL Server 2008，但我想保留任何 DBMS 的通用和任意答案。
直接在操作系统中支持历史数据将使您的应用程序比其他方式复杂得多。一般来说，我不建议这样做，除非你有一个硬性要求来操纵系统内记录的历史版本。
如果仔细观察，对历史数据的大多数要求都属于以下两类之一：
审计日志： 最好使用审计表来完成。通过从系统数据字典中读取元数据，编写一个生成脚本以创建审计日志表和触发器的工具相当容易。这种类型的工具可用于在大多数系统上改进审计日志记录。如果你想实现一个数据仓库，你也可以使用这个子系统来捕获变化的数据（见下文）。
历史报告： 报告历史状态、“当前”位置或一段时间内的分析报告。通过查询上述类型的审计日志表，可以满足简单的历史报告要求。如果您有更复杂的需求，那么为报告实施数据集市可能比尝试将历史直接集成到操作系统中更经济。
缓慢变化的维度是迄今为止跟踪和查询历史状态的最简单的机制，并且大部分历史跟踪都可以自动化。通用处理程序并不难编写。通常，历史报告不必使用最新数据，因此批量刷新机制通常就可以了。这使您的核心和报告系统架构相对简单。
如果您的需求属于这两个类别之一，您最好不要将历史数据存储在您的操作系统中。将历史功能分离到另一个子系统总体上可能会减少工作量，并生成更适合其预期目的的事务和审计/报告数据库。
