我正在领导一个项目，我们将在其中记录指标数据。我想将数据保留很多年。但是，我还想防止主表变得with肿，尽管长期趋势是必需的，而短期报告却不需要这些数据。

处理这种情况的最佳策略是什么？只需将旧数据存档到另一个表？还是通过合并数据本身来"汇总"(然后将其存储到另一个表中)？还是完全其他的东西？

其他信息：我们正在使用SQL Server 2005.

解决方案

回答

这些选项中的任一个都是出色的，但实际上取决于问题域。对于现金余额或者统计数据之类的东西，我认为汇总记录并对其进行合并是最好的方法，然后可以将汇总的记录移到并行存档表中，从而对其进行键控，以便在需要时"展开"必要的。这样可以使主数据表保持干净和快速，但可以保留额外的数据以供审核或者进行其他操作。关键问题是，我们如何实施"汇总"过程。是通过触发器或者服务器端过程自动完成，还是在应用程序级别通过用户干预自动完成？

回答

我们在工作中使用这两种方法，但略有不同，我们将所有销售数据保留在主表中30天，然后在晚上(夜间工作的一部分)将销售天汇总为汇总(n售出x产品出于报表原因，将其保存在单独的表格中，并将超过30天的销售额存档到另一个数据库中，然后每年一次(我们在纳税年度)启动一个新的存档数据库。不是完全完美，但是..

这样，我们可以快速获取摘要数据，随时掌握所有当前销售数据，并拥有无限的空间来保存详细的存档数据。我们确实尝试将所有内容都保存在一个数据库(位于不同的表中)中，但是数据库(中间数据库)的文件大小会变得很大，以至于拖累了系统。

我们唯一真正的问题是访问跨越多个数据库的详细数据，因为连接和断开连接的速度很慢，并且必须使用代码而不是sql进行分析

回答

如果我们使用的是SQL Server 2005，则这可能是使用分区表的不错选择。

回答

@Jason我看不到将数据保存在纯旧文本文件中如何让我们轻松地对数据进行长期趋势分析。

@Jason我想我的意思是，如果商务人员需要对数据进行任何形式的临时分析(即趋势分析)，那么将数据汇总或者存档到文本文件确实无法解决任何问题。当然，编写使用文本文件的代码在许多语言中都很容易，但是已经解决了这个问题。另外，我认为，今天的RDBMS在设置和正确维护时都非常耐用。如果不是，那么为什么我们要在一个业务之上开展业务(更不用说将数据存档到该业务了)？我只是没有看到归档到纯文本文件的意义，因为声称文本文件的持久性优于数据库的持久性。

回答

取决于预算等限制，这听起来像是数据仓库应用程序的理想之选。通常，这将引入一个新服务器用作数据仓库。 SQL Server 2005开箱即用地支持许多此类活动，此外，我们也许能够利用其他SQL Server服务(例如Analysis Services，Reporting Services)为用户提供更多价值。 (请参阅http://www.microsoft.com/technet/prodtechnol/sql/2005/dwsqlsy.mspx)