我正在尝试确定如何存储历史交易数据。
我应该将它存储在一个表中，每次重新插入记录时都会重新插入新的时间戳吗？
我应该将历史数据分解为单独的“历史”表，并仅将当前数据保存在“活动”表中。
如果是这样，我该如何做到最好？使用触发器自动将数据复制到历史表？或者我的应用程序中有逻辑？
根据Welbog的评论更新：
将有大量的历史数据（数十万行 - 最终可能数百万）
主要是对历史数据进行搜索和报告操作。
性能是一个问题。搜索不应该整夜运行以产生结果。
我正在尝试确定如何存储历史交易数据。
我应该将它存储在一个表中，每次重新插入记录时都会重新插入新的时间戳吗？
我应该将历史数据分解为单独的“历史”表，并仅将当前数据保存在“活动”表中。
如果是这样，我该如何做到最好？使用触发器自动将数据复制到历史表？或者我的应用程序中有逻辑？
根据Welbog的评论更新：
将有大量的历史数据（数十万行 - 最终可能数百万）
主要是对历史数据进行搜索和报告操作。
性能是一个问题。搜索不应该整夜运行以产生结果。
如果要求仅用于报告，请考虑构建单独的数据仓库。这使您可以使用数据结构，例如缓慢变化的维度，这些数据对历史报告更好，但在事务系统中不能很好地工作。由此产生的组合还会将历史报告从生产数据库中移除，这将是性能和维护的胜利。
如果您需要在应用程序中使用此历史记录，那么您应该实现某种版本控制或逻辑删除功能，或者使所有内容完全反对并重新进行（即事务永远不会被删除，只需撤消并重新进行重述）。仔细想想你是否 真 需要这个，因为它会增加很多复杂性。制作可以正确重建历史状态的事务性应用程序比看起来要困难得多。财务软件（例如保险承保系统）未能比您想象的那么多。
如果您只需要历史记录用于审计日志记录，请创建影子表和审计日志记录触发器。与在应用程序中正确和全面地实现审计日志记录相比，这更加简单和强大。触发器还将从应用程序外部的源中获取对数据库的更改。
这个问题沿着商业逻辑的路线。首先了解您的业务需求，然后从那里开始。对于这种情况，数据仓库是一个很好的解决方案。 ETL将为您提供处理数据流的许多选项。您对“历史”与“活跃”的基本概念非常正确。如果将数据仓库中的所有维度和事实表保存在数据仓库中，那么您的历史数据将更加高效和灵活。