|
|
5 回复 | 直到 9 年前
|
1
4
我们在工作中使用这两种方法,但略有不同,我们将所有销售数据保留在主表中30天,然后在夜间(部分夜间工作)出于报告原因将销售天数汇总到单独的表中(今天销售的X个产品的数量等),并且将超过30天的销售数据存档到不同的数据库中,然后一次一年(我们继续纳税)一个新的档案数据库启动。不完全完美,但是…… 这样我们就可以快速获得摘要数据,将所有当前的销售数据保存在手边,并为详细的存档数据提供无限的空间。我们确实尝试将其全部保存在一个数据库中(在不同的表中),但数据库(interbase)的文件大小会增长到如此之大,以至于拖累系统。 唯一真正的问题是访问跨越多个数据库的详细数据,因为连接和断开速度很慢,必须用代码而不是SQL进行分析。 |
|
|
2
4
如果您使用的是SQL Server 2005,这可能是使用 partitioned tables . |
|
|
3
2
根据预算等约束条件,这听起来像是数据仓库应用程序的完美候选者。这通常会引入一个用作数据仓库的新服务器。SQL Server 2005开箱即用地支持许多这种活动,而且您还可以利用其他SQL Server服务(例如Analysis Services、Reporting Services)为用户提供附加值。(见 http://www.microsoft.com/technet/prodtechnol/sql/2005/dwsqlsy.mspx ) |
|
|
4
2
@Jason-我不知道将数据保存在简单的旧文本文件中如何使您能够轻松地对数据进行长期趋势分析。 @杰森-我想我的观点是,如果业务人员需要对数据进行任何类型的即席分析(即趋势分析),那么将数据汇总或归档到文本文件实际上并不能解决任何问题。当然,编写代码来使用文本文件在许多语言中都很容易,但这个问题已经得到了解决。另外,我认为今天的RDBMS在正确设置和维护时都非常耐用。如果他们不是,你为什么要在一个之上经营一家企业(更不用说将数据归档到它上面)?我只是不认为归档到纯文本文件的意义,因为有人声称文本文件的耐久性优于数据库。 |
|
|
5
1
这些选项中的任何一个都是很好的,但它实际上取决于问题域。对于现金余额或统计数据之类的事情,我认为汇总记录和合并它们是最好的方法,然后您可以将汇总的记录移动到并行的存档表中,以这样的方式键入它们,以便在必要时“展开”。这样可以保持主数据表的干净和快速,但允许您保留额外的数据以供审计或其他用途。关键问题是,如何实现“上卷”过程。是通过触发器或服务器端进程,还是通过应用程序级别的用户干预,自动进行的? |
推荐文章
|
|
Michael Samuel · MYSQL在以下情况下自动创建索引 6 年前 |
|
|
Patricia Rozario · 数据库设计确保一对一关系 6 年前 |
|
|
dryhay · MySQL“多对多”关系错误 6 年前 |
|
|
L. Fox · 我在这里用的是什么样的Laravel雄辩的关系 7 年前 |
|
|
Geoff Harper · 我应该如何构建关系松散的SQL db 7 年前 |
|
|
waroxx · SQL—当多个表具有相同的列时,最好怎么做 7 年前 |
|
|
Lumpi01 · SQL 2不同的注释类型-最佳解决方案? 7 年前 |
|
|
Hayreddin Tüzel · 预约系统数据库建模[关闭] 7 年前 |