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


9

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

处理这种情况的最佳策略是什么?简单地将旧数据归档到另一个表中?或者通过对数据本身进行整合(然后将其存储到不同的表格)?还是其他什么东西?

附加信息:我们使用SQL Server 2005的

4

我在工作中使用了这两种方法,但略有不同,我们将所有销售数据保留在主表中30天,然后在晚上(夜间工作的一部分)将销售日汇总为摘要(n qty的x产品今天出售等)在一个单独的表中出于报告的原因,超过30天的销售被存档到一个不同的数据库,然后每年一次(我们去税年)开始一个新的档案数据库。不完全的,但..

这样我们快速得到摘要数据,保持所有当前的销售数据在手,并有一个无限的空间,详细的档案数据。我们尝试将它全部保存在一个数据库中(在不同的表格中),但是数据库的文件大小(interbase)会变得非常大以至于会拖累系统。

我们正在访问跨越多个数据库的详细数据,作为连接,唯一真正的问题断开缓慢,分析了在代码中完成,而不是SQL


1

无论这些选项是优秀的,但它确实取决于问题域。对于诸如现金余额或统计数据之类的东西,我认为汇总记录并合并它们是最好的方法,然后您可以将汇总的记录移动到并行归档表格中,以可以“展开”的方式键入它们必要。这使您的主数据表保持清洁和快速,但允许您保留额外的审计数据或其他数据。关键问题是,您如何实施“总结”流程。自动,通过触发器或服务器端流程,还是通过应用程序级别的用户干预?


4

如果您使用的是SQL Server 2005中,这可能是使用partitioned tables的理想选择。


2

@Jason - 我没有看到如何将数据保存在普通的旧文本文件中,这将使您能够轻松地对数据进行长期趋势分析。我想我的观点是,如果商业人士需要对数据进行任何类型的临时分析(即趋势分析),那么将数据卷入或归档到文本文件中并不能解决问题任何问题。当然编写代码来消费文本文件在很多语言中很容易,但是这个问题已经解决了。另外,我认为今天的RDBMS在正确设置和维护时都非常耐用。如果他们不是为什么要在一个顶部运行一个业务(更不用说归档数据了)?由于声明文本文件的持久性优于数据库,我只是看不到归档为纯文本文件的意义。


2

根据预算等约束条件,这听起来像是数据仓库应用程序的完美候选者。这通常会引入一个新的服务器用作数据仓库。 SQL Server 2005支持许多此开箱即用的活动,此外,您还可以利用其他SQL Server服务(例如Analysis Services,Reporting Services)为用户提供额外的价值。 (见http://www.microsoft.com/technet/prodtechnol/sql/2005/dwsqlsy.mspx