方案探讨,关于工程中数据库的问题.
用VB开发的工程,使用SQL Server数据库.
用SQL Server记录历史数据,有几个历史数据的表单,可是这样长年累月的添加记录,弄到这些表单庞大无比,以致对表单进行操作时消耗很长的时间.这个问题就显得很重要的了.
情况具体是这样,有3类表单,1类是1分钟记录一次的表单,1类是20分钟记录一次的表单,这个数据是1分钟表单的平均值记录表单.还有1类是1小时记录一次的表单,这个数据就是20分钟表单的平均值记录.
1分钟记录一次的表单使用1个月就是1*60*24*30=43200条记录,这就有满大了,所以我限制了这个表单的记录条数,在添加一条记录的时候就删除最老的一条,保证这个表单只有1个月的分量.
但是20分钟和1小时的表单我就不能这么做了,因为客户需要保留所有的记录.
曾试过用备份和恢复的方法,但是比较麻烦.请各位大侠看看有何良策,小弟不甚感激!
[解决办法]
但是20分钟和1小时的表单我就不能这么做了,因为客户需要保留所有的记录.
这个要求有点无理了,即便是最先进的系统,最大的磁盘空间也有满的那一天!!
[解决办法]
分表保存
[解决办法]
从你的描述看，你这点数据量并不算大啊。就说你的分钟记录表，一个月才43200，一年才50多万条数据，用10年也就500万数据，也不能称为庞大无比，如果这点数据，对于常规的操作，要消耗很长的时间，是不是硬件或者程序有问题？
[解决办法]
使用sql server的工作调度，写个存储过程，在每天适当的时候（如凌晨3、4点）建一新表，把昨天的数据都移到那个新表去，要统计的时候就用union all把需要的数据并在一起统计。。。然后定时做数据备份，清空旧的数据备份表。。
以前我公司那套系统，平均每秒差不多都会有几十条新记录插入。。。。如果一直放着不管它，早崩溃了。。。。
[解决办法]
50多万条记录进行查询，求平均值等操作，你觉得会快的起来吗？
我在那机器上不开任何其他的程序，就用SQL Server的查询分析器，使用这条命令：
select top 1 * from XXX order by InTime desc
大概用了我８秒的时间．而对数据记录比较少的表单来说，速度就比较快了，可以满足处理的要求．
-------------------------------
这样子的现象只能证明一件事情， 你的数据库结构定义不合理， 适当的对某些字段建立索引，可以有效地提高速度。
[解决办法]
同时你还需要增加一个表,记录什么时候分表了,分表的名称等信息,到查询的时候就把这些表通过你增加的哪个新表联系起来!!
====================================
不需要，只要你自己心里有数就行了。。。
例如，今天是2007.06.01，在2007.06.02的凌晨3：00，工作调度就会执行预先写好的存储过程，大致要完成的工作是：
1.建新表,表名testtable20070601，表结构跟源表（originaltable）一样。
2.从源表中复制2007.06.02前的数据到testtable20070601：
insert into testtable20070601 select * from originaltable where datefield < '2007-06-02 00:00:00.000 '
3.删除源表的旧数据：
delete from originaltable where datefield < '2007-06-02 00:00:00.000 '
4.完成。
到了2007.06.03的凌晨3：00，又重复执行上述操作，只是那时建的新表表名是testtable20070602。由于新表的表名都有规律，要统计时只要找到需要的那些日期的表把它们union all再统计就行了。。。只是根据需要构建一个sql查询语句，简单的字符串操作而已。。。
有需要的话，另做一个存储过程，也放在工作调度里。。作用是定时备份，例如，每个月的1号凌晨4：00（为了不与上面3：00那个冲突），使用sql server的dts功能把testtable20070601、testtable20070602、testtable20070603等表导出为xls文件。存放于特定目录。然后再设一个时间判断，每导出一个月的数据，就把相隔几个月前的数据表删除。例如今天是2007.6.1，凌晨3：00的时候就把testtable20070501、testtable20070502......testtable20070531表导出到目录存放，然后把2007.04.01前的备份表testtable20070301、testtable20070302从库里删除（drop table？？？？）。。。这时不把testtable20070401～testtable20070531也一并删除掉，是预防在导出时出现问题而又删掉源数据就麻烦了。。。有一两个月的时间让你检查导出后的xls文件是否有问题，总足够了吧。。。。另外一种做法是在工作调度中直接做备份，把上面说的那些数据实时备份出来，记得好像是一个mdb文件和一个ldf文件。
这种方法可以让你保留全部数据记录而又不会降低服务器效率及可以大量节省存储空间（以前我把备份出来的数据文件用winrar最大压缩，压缩比约为10：1）。。
[解决办法]
尤其是更加精确的查询，耗时更多，象：
select * from XXX where InTime between '2003-01-01 ' and '2003-05-30 '
------------------------------------------------
觉得还是楼主的数据库设计有问题，象上面的这条语句，即使数据有100万的，如果数据库设计比较好的话，处理也应该是毫秒级的，建议楼主先试一下把InTime这个字段设置为聚集索引看看,建议楼主看下这篇文章：
http://blog.csdn.net/great_domino/archive/2005/02/01/275839.aspx
[解决办法]
但是20分钟和1小时的表单我就不能这么做了,因为客户需要保留所有的记录.
－－－－－
既然用户只需要保留20分钟和1小时数据的所有记录，则1分钟的记录还用得着保存一个月吗？只用20条就可以了。不会是一次性对一个月的1分钟数据进行统计才生成20分钟和1小时的数据吧，那太低效了。
20分钟和1小时的表单，用户要求保留，那就这样了。
但这样会产生两个头疼结果：
1.硬盘容易满。
解决方法就是备份，没啥说的。啥麻烦不麻烦，用户要求不改变的情况下，除了这个还能有什么办法？何况这也不很麻烦。实际上任何象样的数据库应用软件都必须做好备份和恢复工作的，这是基本。
2.数据操作效率低。
既然量是没法压缩的，就得讲究量的组织形式了。好的组织形式自然可以不受量的影响而致效率问题。合理地分表是少不了的。定期的备份清除也可能需要考虑，那就看具体情况了。
[解决办法]
搂主可能没看过ASP海量数据查询的东西吧，那么点数据要花那么久时间，肯定是代码问题。
还有说到数据量和查询速度，SQL Server 2005 快很多，不防看看，我是深有体会，但是几十万条的数据
只要不超过1G,Access的数度都不慢，何况SQL Server
[解决办法]
建议你采用分表记录联合查询...
建立分表的时候, 得采用有规律的表名称~~~
我记得以前我做过很多这样的生产数据记录, 都采用的分表...
其数据量比你的大得多, 1分钟每个反应罐(有20个反应罐)要保存3条数据... 查询的时候都没有出现那样的问题...
