我和一些同事就存储历史数据的最佳方法进行了辩论。当前，对于某些系统，我使用一个单独的表来存储历史数据，并且为当前的活动记录保留一个原始表。因此，假设我有表FOO。在我的系统下，所有活动记录都将进入FOO，所有历史记录都将进入FOO_Hist。用户可以更新FOO中的许多不同字段，因此我想对所有更新内容保持准确的了解。FOO_Hist保留与FOO完全相同的字段，但自动递增的HIST_ID除外。每次FOO更新，我执行插入语句插入FOO_Hist类似于：insert into FOO_HIST select * from FOO where id = @id。
我的同事说这是错误的设计，因为出于历史原因，我不应该拥有表的确切副本，而应该在活动表中插入另一个记录，并带有一个标志，表明该记录是出于历史目的。
是否有处理历史数据存储的标准？在我看来，考虑到可能超过一百万条记录，我不想将我的活动记录与所有历史记录都放在同一张表中（我在考虑长期）。
您或您的公司如何处理？
我正在使用MS SQL Server 2008，但我想保留所有DBMS的通用和任意答案。
Answers:
直接在操作系统中支持历史数据将使您的应用程序比以前更加复杂。通常，除非您有严格的要求在系统内处理记录的历史版本，否则我不建议您这样做。
如果仔细观察，对历史数据的大多数需求都属于以下两类之一：
审核日志记录： 最好使用审核表来完成。编写一个可以生成脚本以通过从系统数据字典中读取元数据来创建审核日志表和触发器的工具相当容易。这种类型的工具可用于在大多数系统上改造审核日志记录。如果要实现数据仓库，也可以使用此子系统来更改数据捕获（请参见下文）。
历史报告：关于历史状态，“原样”职位的报告或一段时间内的分析报告。通过查询上述类型的审核日志记录表，可以满足简单的历史报告要求。如果您有更复杂的要求，那么为报表实现数据集市可能比尝试将历史记录直接集成到操作系统中更为经济。
到目前为止，缓慢更改尺寸是跟踪和查询历史状态的最简单机制，并且大多数历史跟踪可以自动进行。通用处理程序并不难编写。通常，历史报告不必使用最新数据，因此批量刷新机制通常很好。这样可以使您的核心和报告系统体系结构相对简单。
如果您的需求属于这两类之一，则最好不要在操作系统中存储历史数据。将历史功能分离到另一个子系统中，总体上可能会花费较少的精力，并且可以生成交易和审核/报告数据库，这些数据库可以更好地实现其预期目的。
我不认为有特定的标准方法，但我认为我会提出一种可能的方法。我在Oracle和我们内部的Web应用程序框架中工作，该框架利用XML来存储应用程序数据。
我们使用一种称为“主从细节”模型的模型，它最简单的组成包括：
例如，所谓的主表Widgets通常仅包含一个ID。通常会包含不会随时间变化/不是历史数据。
细节/历史表例如称为Widget_Details至少包含：
因此，从本质上讲，一个实体首先要在主体中具有1行，在详细信息中具有1行。结束日期为NULL且STATUS_CONTROL为“ C”的明细。发生更新时，当前行将更新为具有当前时间的END_DATETIME，并且status_control设置为NULL（如果需要，则设置为“ A”）。在明细表中会创建一个新行，并仍然链接到同一主表，并带有status_control'C'，进行更新的人员的ID和存储在XMLDATA列中的新数据。
这是我们历史模型的基础。创建/更新逻辑在Oracle PL / SQL包中处理，因此您只需向函数传递当前ID，您的用户ID和新的XML数据，并在内部进行所有更新/插入行以在历史模型中表示该行。开始时间和结束时间指示表中该行处于活动状态的时间。
存储价格便宜，我们通常不删除数据，而是希望保留审核记录。这使我们可以随时查看数据。通过为status_control ='C'编制索引或使用View，杂乱不成问题。显然，您的查询需要考虑到您应该始终使用记录的当前版本（NULL end_datetime和status_control ='C'）。
更改数据捕获：https : //docs.microsoft.com/zh-cn/sql/relational-databases/track-changes/about-change-data-capture-sql-server?view=sql-server-2017
它在SQL Server 2008 R2中受支持，在SQL Server 2008中可能已受支持。
这个问题比较老，但是人们仍然在研究这个问题。因此，如果您使用的是oracle，则可能会对oracle闪回感兴趣：http : //docs.oracle.com/cd/B28359_01/appdev.111/b28424/adfns_flashback.htm
只是想添加一个我开始使用的选项，因为我使用Azure SQL，而多表的事情对我来说太麻烦了。我在表上添加了插入/更新/删除触发器，然后使用“ FOR JSON AUTO”功能将之前/之后的更改转换为json。
SET @beforeJson = (SELECT * FROM DELETED FOR JSON AUTO)
SET @afterJson = (SELECT * FROM INSERTED FOR JSON AUTO)
这将返回更改前后的记录的JSON表示形式。然后，我将这些值存储在具有更改发生时间的时间戳的历史记录表中（我还存储当前关注记录的ID）。使用序列化过程，我可以控制在更改架构的情况下如何回填数据。
我得知这个从这个链接点击这里
您可以对表进行分区吗？
“使用SQL Server 2008进行分区的表和索引策略当数据库表的大小增长到数百GB或更多时，加载新数据，删除旧数据和维护索引会变得更加困难。仅表的绝对大小这会导致此类操作花费更长的时间。甚至必须加载或删除的数据也可能非常庞大，从而使对表的INSERT和DELETE操作变得不切实际。MicrosoftSQL Server 2008数据库软件提供了表分区功能，以使此类操作更易于管理。”
另一种选择是按[每日|每小时|任何时间]存档运行数据。大多数数据库引擎支持将数据提取到存档中。
基本上，这个想法是创建一个计划的Windows或CRON作业，
许多SQL数据库引擎随附可用于此目的的工具。例如，在Linux上使用MySQL时，可以在CRON作业中使用以下命令来调度提取：
mysqldump --all-databases --xml --lock-tables=false -ppassword | gzip -c | cat > /media/bak/servername-$(date +%Y-%m-%d)-mysql.xml.gz
我知道这个旧帖子，但只想补充几点。这些问题的标准是最适合这种情况的标准。了解这种存储的必要性以及历史/审计/变更跟踪数据的潜在使用非常重要。
审核（出于安全目的）：将公用表用于所有可审核表。定义结构以存储列名，值之前和之后的字段。
存档/历史记录：对于诸如跟踪先前的地址，电话号码等情况，创建单独的表FOO_HIST会更好，如果您的活动事务表架构将来不会发生重大变化（如果您的历史表必须具有相同的结构）。如果您期望表标准化，列的数据类型更改增加/删除，则以xml格式存储历史数据。使用以下列（ID，日期，架构版本，XMLData）定义一个表。这将轻松处理架构更改。但是您必须处理xml，这可能会为数据检索带来一定程度的复杂性。
您可以使用MSSQL Server审核功能。在SQL Server 2012版本中，您将在所有版本中找到此功能：
您可以在表上创建物化/索引视图。根据您的要求，您可以对视图进行全部或部分更新。请查看此内容以创建mview并记录。如何在SQL Server中创建实例化视图？