保留大数据集的最佳策略是什么？
我正在领导一个项目，我们将记录指标数据。我想保留这些数据多年。不过，我还想避免主表中的数据变得臃肿，而这些数据虽然对于长期趋势来说是必要的，但对于短期报告并不需要。保留大数据集的最佳策略是什么？
处理这种情况的最佳策略是什么？简单地将旧数据归档到另一个表中？或者通过对数据本身进行整合（然后将其存储到不同的表格）？还是其他什么东西？
附加信息：我们使用SQL Server 2005的
我在工作中使用了这两种方法，但略有不同，我们将所有销售数据保留在主表中30天，然后在晚上（夜间工作的一部分）将销售日汇总为摘要（n qty的x产品今天出售等）在一个单独的表中出于报告的原因，超过30天的销售被存档到一个不同的数据库，然后每年一次（我们去税年）开始一个新的档案数据库。不完全的，但..
这样我们快速得到摘要数据，保持所有当前的销售数据在手，并有一个无限的空间，详细的档案数据。我们尝试将它全部保存在一个数据库中（在不同的表格中），但是数据库的文件大小（interbase）会变得非常大以至于会拖累系统。
我们正在访问跨越多个数据库的详细数据，作为连接，唯一真正的问题断开缓慢，分析了在代码中完成，而不是SQL
无论这些选项是优秀的，但它确实取决于问题域。对于诸如现金余额或统计数据之类的东西，我认为汇总记录并合并它们是最好的方法，然后您可以将汇总的记录移动到并行归档表格中，以可以“展开”的方式键入它们必要。这使您的主数据表保持清洁和快速，但允许您保留额外的审计数据或其他数据。关键问题是，您如何实施“总结”流程。自动，通过触发器或服务器端流程，还是通过应用程序级别的用户干预？
@Jason - 我没有看到如何将数据保存在普通的旧文本文件中，这将使您能够轻松地对数据进行长期趋势分析。我想我的观点是，如果商业人士需要对数据进行任何类型的临时分析（即趋势分析），那么将数据卷入或归档到文本文件中并不能解决问题任何问题。当然编写代码来消费文本文件在很多语言中很容易，但是这个问题已经解决了。另外，我认为今天的RDBMS在正确设置和维护时都非常耐用。如果他们不是为什么要在一个顶部运行一个业务（更不用说归档数据了）？由于声明文本文件的持久性优于数据库，我只是看不到归档为纯文本文件的意义。
根据预算等约束条件，这听起来像是数据仓库应用程序的完美候选者。这通常会引入一个新的服务器用作数据仓库。 SQL Server 2005支持许多此开箱即用的活动，此外，您还可以利用其他SQL Server服务（例如Analysis Services，Reporting Services）为用户提供额外的价值。 （见http://www.microsoft.com/technet/prodtechnol/sql/2005/dwsqlsy.mspx）