我正在领导一个项目，我们将记录指标数据。我想保留数据多年。但是，我还想防止主表因数据而变得臃肿，这些数据虽然对于长期趋势是必要的，但对于短期报告来说却不是必需的。
处理这种情况的最佳策略是什么？只是将旧数据归档到另一个表？还是通过对数据本身进行一些整合来“汇总”（然后将其存储到不同的表中）？还是完全不同的东西？
附加信息：我们使用的是 SQL Server 2005。
scottmarlowe
问问题
721 次
5 回答
4
我们在我的工作中使用这两种方法，但略有不同，我们将所有销售数据保留在主表中 30 天，然后在晚上（夜间工作的一部分）将这些天的销售额汇总到摘要中（n 数量的 x 销售产品今天等）出于报告原因在单独的表中，并且超过 30 天的销售额被存档到不同的数据库中，然后每年一次（我们继续纳税年度）启动一个新的存档数据库。不完全完美但是..
通过这种方式，我们可以快速获取摘要数据，将所有当前销售数据保存在手边，并为详细的存档数据提供无限空间。我们确实尝试将它们全部保存在一个数据库中（在不同的表中），但是数据库（interbase）的文件大小会变得如此之大，以至于它会拖累系统。
我们唯一真正的问题是访问跨多个数据库的详细数据，因为连接和断开连接很慢，并且必须在代码中而不是 sql 中进行分析
于 2008-08-21T12:54:23.463 回答
4
如果您使用的是 SQL Server 2005，这可能是使用分区表的好选择。
于 2008-08-21T13:02:24.130 回答
2
@Jason - 我看不出将数据保存在普通的旧文本文件中如何让您轻松地对数据进行长期趋势分析。
@Jason - 我想我的意思是，如果业务人员需要对数据进行任何类型的临时分析（即趋势分析），那么将数据汇总或归档到文本文件确实不能解决任何问题。当然，在许多语言中编写代码来使用文本文件很容易，但是这个问题已经解决了。另外，我认为今天的 RDBMS 在正确设置和维护时都非常耐用。如果它们不是，您为什么要在一个基础上开展业务（更不用说将数据归档到其中了）？我只是没有看到归档到纯文本文件的意义，因为声称文本文件的持久性优于数据库的持久性。
于 2008-08-21T13:39:29.300 回答
2
根据预算等限制，这听起来像是数据仓库应用程序的完美候选者。这通常会引入一个新的服务器用作数据仓库。SQL Server 2005 支持许多开箱即用的活动，此外，您还可以利用其他 SQL Server 服务（例如 Analysis Services、Reporting Services）为您的用户提供额外的价值。（见http://www.microsoft.com/technet/prodtechnol/sql/2005/dwsqlsy.mspx）
于 2008-08-21T13:47:48.220 回答
1
这些选项中的任何一个都非常好，但这实际上取决于问题域。对于现金余额或统计数据之类的东西，我认为汇总记录并合并它们是最好的方法，然后您可以将汇总的记录移动到并行存档表中，以这样一种方式键入它们，以便您可以“展开”如果必要的。这使您的主数据表保持干净和快速，但允许您保留额外的数据以进行审计或其他任何事情。关键问题是，您如何实施“汇总”流程。是自动通过触发器或服务器端进程，还是通过应用程序级别的用户干预？
于 2008-08-21T12:36:42.430 回答