到目前为止，我曾使用过一些数据库，但其中的理念非常不同。这让我想知道，
在业务应用程序中出于历史目的复制表格是个好主意吗？
我所说的商业应用是指: 企业用来管理其所有数据(例如发票、客户、库存 [如果适用] 等)的软件
“复制表格”是指: 当，比方说你的发票过时了(比如一年后，开具发票和付款后，w/e)，你可以将它们存储到“历史”表中，这使得它们可以进行咨询，但不应该被修改。同样的事情，客户多年不活跃。
优点:
使用历史表可以通过实际使用的数据加速研究，因为它使您实际使用的表更小。
更好地分离历史数据和实际数据
更容易从数据库中删除数据以将其存储在硬介质上，而不会影响您的数据库(更可预测，因为数据在历史表中没有机会被使用)。当您获得未使用的数据 10 年后，通常会发生这种情况。
缺点:
让您的数据库拥有最多 2 倍的表。
让你的数据库更复杂
使您的报告程序更加复杂，因为有时您必须导入两倍数量的表格。
最佳答案
存档是企业应用程序的一个关键方面，但一般来说，我建议不要使用它，除非您真的非常需要它。
归档意味着您要么接受无法在特定日期之前获取历史数据，要么创建一些方案来管理“当前”和“历史”数据；您的解决方案(存档表)是解决此问题的一种方法。
这两种解决方案都不是那么好 - 归档表意味着大量重复的代码/数据、复杂的归档过程(尤其是外键关系)、大量出错的机会。
我确实相信“时间”的概念应该与可变性一起融入到大多数业务应用程序的领域和数据模型中——你不应该在订单发生后改变它已确认，但您应该能够将产品添加到新订单。
至于你的优点:
一般而言，除非您谈论的是非常非常大规模的企业，否则我认为您不会注意到性能影响。我不认为 - 在现代 SQL 服务器解决方案中 - 你会注意到查询 10.000 条客户记录或 1.000.000 条客户记录之间的速度差异。
“历史性”的定义实际上相当棘手 - 大多数企业出于监管和税收目的必须保留历史性数据，通常需要很多年；他们可能希望能够分析几年的趋势等。如果企业希望了解“过去 5 年我们每月销售了多少小部件”，这意味着您必须保留 5 年的数据以某种方式(“原始”或预聚合)。
是的，分离数据会更容易。今天构建一个功能 - 每次更改应用程序时都必须维护 - 在 10 年内获得返回对我来说似乎是一项糟糕的投资...
关于database - 业务应用程序中的历史数据，我们在Stack Overflow上找到一个类似的问题： https://stackoverflow.com/questions/6624596/