当前位置：首页 >

对文件的操作到底对程序的执行效率能影响多少？


操作文件的时候会比较耗费资源，效率会比较差。
但是，有没有哪位大侠比较测试过，到底差多少阿？
对于效率要求比较高的程序，有什么好的解决办法吗？

我们现在常常为了提高速度，不得不在一个表里放一大堆字段，争取一次能读出来
最多的可用数据。但是这样搞得数据库的设计常常会不规范。唉！

 多情包子 回复于：2003-11-12 22:25:07
看看你的数据库的索引是否合理!我曾经做过一个程序,从几个数据库中收集有用的数据做统计,一开始运行要花费差不多45分钟!在对数据分析后建立了一个相对合理的索引,程序运行1分钟多点就好了.试着看看对数据库的所以有什么可以改善的

 aeiou 回复于：2003-11-13 13:34:09
这个已经尽量改善了，现在主要考虑的是打开文件所耗费的资源。

比如两个文件：
产品文件，包含了产品的属性外，还有该产品的供应商是哪个。
供应商主文件，包含供应商的名称、编码、地址、联系人、供应类型等等信息。

如果查询产品信息的时候，需要同时列出该产品供应商的相关信息，这时候一般的处理方式是：
1。搜索产品文件，找到需要查询的产品，
2。根据产品文件中的供应商代码，搜索供应商文件，得到供应商的信息，
3。把产品信息和供应商信息一起列出来以供查询。

以上处理过程需要执行两次 打开文件 的操作。
而如果把供应商信息和产品信息放在一个文件的话，只要打开一次文件，就可以把信息全部得到。

但是就数据库设计的合理性来说，我觉得应该是分开存储比较好。
合起来纯粹是为了执行效率考虑。那么这个代价是否值得？难道为了运行速度，就只能使用这种冗余的数据库设计吗？

 aeiou 回复于：2003-11-13 19:02:41
顶一下。
有谁帮忙出谋划策阿？

 aeiou 回复于：2003-11-28 15:27:35
没有人测试过吗？

给个看法啊~~

 brent_wu 回复于：2004-01-02 21:45:30
你的问题太大，太复杂。
你应该具体分析你的应用，选择合适的开发工具，然后再考虑数据库的设计，包括如何合理地建立索引。
比如如果你的大部分交易都要用到这两个文件，那把它们合并起来没问题；如果你的大部分交易只用到其中一个，那把它们合并起来反而会降低系统的效率。
索引的建立也要合理，索引的确可以降低数据库搜索的次数，但索引文件的维护也要占用系统的开销，同一个文件索引文件太多、太复杂了也会带来新的问题，包括建立索引的顺序、在应用中查询时使用索引字段的顺序都会影响到系统的效率。
系统开发过程中如果没有考虑到效率问题的话，后期的维护要带来太多的麻烦。我深有体会。

 wildfish 回复于：2004-01-03 08:33:19
可以用临时文件的，将这些需要的数据组合到临时文件，这样速度可以比较省事，不论从数据库设计还是效率上都是可以接受的。

 sean810 回复于：2004-01-03 10:05:44
1.建立合理的key,这样能提高数据搜索的效率；同时还要在程序中写合理的查询语句，这也是提高效率的关键；
2.同意楼上的意见，再qtemp中建立wrkfile，同样比较方便的。

 utirei 回复于：2005-04-12 23:12:59
我们现在做的是客户方不同意建立索引文件，原因大家也应该清楚，占据磁盘空间~。
但是2个表的1万-2万的数据量，而且所取的字段并非键字，读起来速度非常之慢~

 wildfish 回复于：2005-04-13 20:32:05
索引建的好，而且要多考虑。这样才可以减少空间，当然了，对于as400不建立索引真的是浪费而且造成效率低下

 cy767 回复于：2005-04-14 00:43:56
从原理上， 两类不同的信息应该分开， 除非你的情况特别特殊。
可以试验一下用opnqryf 或者 join LF 或者 SQL view......

从提高数据读写效率的角度， 可以考虑blocking. 但是因为限制条件比较多， 所以要看具体的应用需求才能知道是否会有大的帮助。

 riancy1106 回复于：2005-04-14 18:00:49
这两者本身就是一个矛盾，即要考虑系统运行提高效率，也要考虑数据库设计的可扩展性。一旦数据库设计不合理，日后修改数据库结构将会变得异常困难，而完全按照软件工程进行数据库设计又造成程序访问数据库效率低下，只能视具体情况而定了！

 aeiou 回复于：2005-04-14 20:01:55
考虑具体情况的话，如果是个小系统也还好说啦，可是如果是个投入近百人，项目工期要2年以上的大项目呢？项目本身对执行效率的要求很高，因为是要全国应用的，每天的业务处理量很大。

临时文件的方法对于数据的完整性和稳定性有没有影响？如果有大量的并发操作会不会有问题呢？

BLOCK的方法没有采用，因为只有大片大片顺序读下来的时候才有用，所以实际效果并不好。

OPNQRYF等操作效率更差，还不如直接打开文件。

现在采用的是在PJ一开始就把常用的文件属性改成SHARE OPEN，然后在程序中又使用缓冲区等做法。同时为了减少对文件的IO操作，很多附属的文件就都跟主文件和在一起了，结果有很多冗余的字段。

现在来看，效率是差不多了，但是有一些副作用，主要是文件结构的设计问题，因为有很多附属的冗余内容，导致文件结构的不稳定，经常要变化。

我在想，牺牲设计上的一些优势来避免文件的IO操作，是不是值得？

 cy767 回复于：2005-04-15 00:37:21
你也许有足够的理由决定那样设计， 但是负作用也比较明显， 比如数据结构的稳定性， 还有当文件SIZE增长到一定程度时带来的潜在的问题， 如果存储成本不在考虑之内的话。

不知道你所提到的应用主要是批处理为主， 还是交互查询为主， 设计方向上当然会有不同。 blocking 也可以用在交互查询程序里， 比如一次读入的记录数和subfile 的记录数一致......

有人说opnqryf 的效率不好， 但是也有人反映opnqryf 在自己的应用里效率非常好， 因为可以对它进行最大程度的控制和优化。SQL view 或者 LF 的效率也许会更好。 对于如此大的项目， 结论还是值得通过试验来确定的。

 胖有型 回复于：2005-04-18 01:45:38
对文件的操作真的会对程序的执行效率影响很多，很多，很多。。。。

建索引是一个好办法，另外如果程序是因为调用某几个大文件，而导致效率低下（比如说几百W或上千W条记录的文件）的话，除了改善程序逻辑，尽量减少无效循环之外，还可以试试SETOBJACC这个命令将文件先写入内存再运行程序，如果没有写操作的话，速度将会提高很多，比如说五到十倍。
当然，前提是你的内存得足够大。


最热门文章推荐：
>· .net组件
>· 组件对象模型
>· 无组件上传图片
>· fat ntfs
>· ntfs启动盘
>· it女性
>· it外包
>· it公司
 ↓相关文章：
© 2006-2008 All Rights Reserved