database-design - 如何存储历史数据

Question

关闭。此题需要 details or clarity 。目前不接受答案。

---

想要改进这个问题吗？通过 editing this post 添加详细信息并澄清问题.

已关闭 2 年前。

Improve this question

我和一些同事就存储历史数据的最佳方式进行了争论。目前，对于某些系统，我使用单独的表来存储历史数据，并为当前事件记录保留原始表。所以，假设我有表 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 的通用和任意答案。

Answer 1

直接在操作系统中支持历史数据将使您的应用程序比其他方式更加复杂。一般来说，我不建议这样做，除非您有在系统内操作记录的历史版本的硬性要求。

如果仔细观察，大多数历史数据要求都属于以下两类之一:

• 审核日志记录:最好使用审核表来完成此操作。编写一个工具来生成脚本来通过从系统数据字典读取元数据来创建审计日志表和触发器是相当容易的。这种类型的工具可用于改进大多数系统的审计日志记录。如果您想实现数据仓库，您还可以使用此子系统来捕获更改的数据(见下文)。

• 历史报告:报告历史状态、“当前”位置或一段时间内的分析报告。通过查询上述类型的审计日志表可以满足简单的历史报告要求。如果您有更复杂的需求，那么为报告实现数据集市可能比尝试将历史直接集成到操作系统中更经济。
  
  缓慢变化的维度是迄今为止最简单的机制。跟踪和查询历史状态，并且大部分历史跟踪都可以自动化。通用处理程序并不难编写。一般来说，历史报告不必使用最新数据，因此批量刷新机制通常就可以。这使您的核心和报告系统架构相对简单。

如果您的要求属于这两类之一，那么您最好不要将历史数据存储在操作系统中。将历史功能分离到另一个子系统中可能会减少总体工作量，并生成能够更好地实现其预期目的的事务和审计/报告数据库。