业务应用程序中的历史数据

Question

到目前为止，我已经与一些数据库合作，并且哲学不同。它让我感到疑惑，

在业务应用程序中复制用于历史目的的表是一个好主意吗？

通过商务应用我的意思是： 企业用于管理其所有数据的软件（例如发票，客户，股票[如果适用]等）

通过'复制表'我的意思是： 当，让我们说你的发票，过时（比如一年后，开发票和付款后，w / e），你可以将它们存储在“历史”表中，这使得它们可以进行咨询，但需要修改。客户多年来一直处于非活动状态。

优点：

使用历史表可以加速对实际使用数据的研究，因为它会使实际使用的表变小。

更好地分离历史数据和实际数据

更容易从数据库中删除数据以将其存储在硬盘上而不会影响您的数据库（更可预测的是因为数据因为它在历史表中而无法使用）。这种情况经常发生在您未使用数据的10年后。

缺点：

使您的数据库最多可以增加2倍。

让您的数据库更复杂

使您的程序对于报表更复杂，因为您有时必须导入两倍的表。

Answer 1

归档是企业应用程序的一个关键方面，但总的来说，除非你确实需要，否则我建议不要使用它。

归档意味着您接受在特定日期之前无法获取历史数据，或者您创建了一些用于管理“当前”和“历史”数据的方案;您的解决方案（存档表）是解决此问题的一种方法。

两种解决方案都不是很好 - 归档表意味着大量重复的代码/数据，复杂的归档程序（尤其是外键关系），错误的机会很多。

我做相信“时间”的概念应该被纳入大多数商业应用程序的域和数据模型中，同时还有可变性 - 一旦订单出现，您就无法更改订单已确认，但您应该能够将产品添加到新订单中。

至于你的专业人士：

总的来说，除非你在谈论非常大规模的业务，否则我认为你不会注意到性能影响。我不认为 - 在现代SQL服务器解决方案上 - 您会注意到查询10.000个客户记录或1.000.000个客户记录之间的速度差异。

“历史性”的定义实际上相当棘手 - 大多数企业必须保持历史悠久的监管和税收目的，通常多年;他们可能希望能够分析几年来的趋势等。如果企业希望看到“我们在过去5年中每月销售多少小部件”，这意味着您必须保留5年的数据不知何故（“原始”或预先聚合）。

是的，分离数据会更容易。今天构建一个功能 - 每次更改应用程序时都必须维护 - 在10年内获得回报似乎对我来说投资不足......

Answer 2

我只有一个“重复”类型表来存储每条记录的历史VERSIONS，比如更改日志。即使更改日​​志也不重复，因为它必须有关于何时更改的信息等。作为一般做法，我不建议将行从活动表迁移到历史表。您必须管理不同版本的查询才能在两个位置查找数据！使用状态控制是否可以更改数据。如果特定应用存在特定情况，我可以看到它可以完成。一旦开始添加外键，就很难删除数据。如果您有一个真正的企业业务应用程序并且您试图删除发票，那么FK与其他表，应付账款/应收账款，原材料成本，销售利润，运输信息等有各种各样的问题。