sql - 如何最好地处理历史数据的存储？

Question

我正在尝试确定我应该如何存储历史交易数据。

我是否应该将它存储在一个表中，每次都会用新的时间戳重新插入记录？

我是否应该将历史数据分解为单独的“历史”表，并且只将当前数据保留在“活动”表中。

如果是这样，我该怎么做才能最好？使用自动将数据复制到历史表的触发器？或者在我的应用程序中使用逻辑？

根据 Welbog 的评论更新：

将有大量历史数据（数十万行 - 最终可能是数百万行）

主要搜索和报告操作将在历史数据上运行。

性能是一个问题。搜索不应该整夜运行以产生结果。

Answer 1

如果要求仅用于报告，请考虑构建单独的数据仓库。这使您可以使用数据结构，例如缓慢变化的维度，这些数据结构更适合历史报告，但在事务系统中效果不佳。由此产生的组合还将历史报告从您的生产数据库中移出，这将是性能和维护方面的胜利。

如果您需要在应用程序中使用此历史记录，那么您应该实现某种版本控制或逻辑删除功能，或者使所有内容完全相反并重新声明（即事务永远不会被删除，只是被撤消和重新声明）。仔细考虑你是否真的需要这个，因为它会增加很多复杂性。制作一个可以正确重建历史状态的事务应用程序比看起来要困难得多。财务软件（例如保险承保系统）在这方面做得比您想象的要多得多。

如果您仅需要将历史记录用于审计日志，请制作影子表和审计日志触发器。这比尝试在应用程序中正确和全面地实现审计日志记录更简单、更健壮。触发器还将从应用程序外部的源中获取对数据库的更改。

Answer 2

这个问题符合业务逻辑。首先了解您的业务需求，然后从那里开始。对于这种情况，数据仓库是一个很好的解决方案。ETL 将为您提供许多处理数据流的选项。您对“历史”与“活动”的基本概念是非常正确的。如果将历史数据保存在包含所有维度和事实表的数据仓库中，您的历史数据将更加高效和灵活。