保留大型数据集的最佳策略是什么？

Question

我正在领导一个项目，我们将在其中记录指标数据。我想将数据保留多年。但是，我还希望防止主表因数据而变得臃肿，这些数据虽然对于长期趋势是必要的，但对于短期报告来说却不是必需的。

处理这种情况的最佳策略是什么？简单地将旧数据归档到另一个表吗？或者通过数据本身的一些整合来“汇总”（然后将其存储到不同的表中）？或者完全是别的什么？

附加信息：我们使用的是 SQL Server 2005。

Answer 1

我们在工作中使用这两种方法，但略有不同，我们将所有销售数据保留在主表中 30 天，然后在晚上（夜间工作的一部分）将销售天数汇总到摘要中（售出的 x 产品的数量）今天等）出于报告原因放在一个单独的表中，并且超过 30 天的销售被存档到不同的数据库中，然后每年（我们继续纳税年度）启动一个新的存档数据库。不完全完美但是..

通过这种方式，我们可以快速获取摘要数据，将所有当前销售数据保存在手边，并为详细的存档数据提供无限的空间。我们确实尝试将所有内容保存在一个数据库中（在不同的表中），但是数据库（interbase）的文件大小会变得如此之大，以至于会拖累系统。

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

Answer 2

如果您使用的是 SQL Server 2005，这可能是一个很好的选择 分区表.

Answer 3

根据预算等限制，这听起来像是数据仓库应用程序的完美候选者。这通常会引入一个新服务器用作数据仓库。SQL Server 2005 开箱即用地支持许多此类活动，此外您还可以利用其他 SQL Server 服务（例如分析服务、报告服务）为您的用户提供附加价值。（看 http://www.microsoft.com/technet/prodtechnol/sql/2005/dwsqlsy.mspx)

Answer 4

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

@Jason - 我想我的观点是，如果有任何类型的临时分析（即趋势分析）需要由业务人员对数据进行处理，将数据汇总或归档到文本文件实际上并不能解决任何问题。当然，在许多语言中编写代码来使用文本文件很容易，但这个问题已经解决了。另外，我认为，如果设置和维护得当，今天的 RDBMS 都非常耐用。如果不是，您为什么要在其之上运行业务（更不用说将数据存档到其中）？我只是不认为归档到纯文本文件有什么意义，因为有人声称文本文件的持久性优于数据库。

Answer 5

这两个选项都很好，但它实际上取决于问题领域。对于现金余额或统计数据之类的事情，我认为滚动记录并合并它们是最好的方法，然后您可以将滚动的记录移动到并行存档表中，以这样的方式键入它们，以便您可以在以下情况下“展开”：必要的。这可以使您的主数据表保持干净和快速，但允许您保留额外的数据以进行审计或其他操作。关键问题是，如何实施“汇总”流程。是通过触发器或服务器端进程自动进行，还是通过应用程序级别的用户干预？