Z zaoya Unregistered / Unconfirmed GUEST, unregistred user! 1999-07-26 #1 本人做的工作,DB数据库近百兆,想用Delphi将其动态压缩与施放, 1、用现有工具好、还是自己编程? 2、自己编程用何算法最好?
T tqz Unregistered / Unconfirmed GUEST, unregistred user! 1999-07-26 #2 压缩,当然可以,delphi有很多带源代码的压缩控件。只要你能够忍受浪费在这上面 的时间。
J Jams Unregistered / Unconfirmed GUEST, unregistred user! 1999-07-26 #3 我也较感兴趣! to tqz 难道没有好的(快的)压缩算法吗?
W wangkun Unregistered / Unconfirmed GUEST, unregistred user! 1999-07-26 #4 如果是用现有的工具,必须将数据库作为一个整体进行压缩,在使用前再借压缩. 很不方便,而且由于数据库的近百M,需要额外同样大的的空间用于还原. 如果使用压缩控件,可以对数据库中的备注字段等等字段在读出时解压缩,在写入前压缩,这样压缩还原的执行是按需发生的.应该说没有浪费时间,如果有浪费时间也可以从整个数据库尺寸的减小上得到好处. 我做过一个程序使用压缩算法来压缩我的二进制字段,效果不错.该压缩控件的输入输出接口使用流. 该控件地址为:http://vcl.vclxx.com/DELPHI/D32FREE/TLZRW1.ZIP 说明:提供 LZRW1/KH 或 LZH 算法数据压缩解压缩的构件 ( 2.01.00 版,附源码 ),作者: Danny Heijl
如果是用现有的工具,必须将数据库作为一个整体进行压缩,在使用前再借压缩. 很不方便,而且由于数据库的近百M,需要额外同样大的的空间用于还原. 如果使用压缩控件,可以对数据库中的备注字段等等字段在读出时解压缩,在写入前压缩,这样压缩还原的执行是按需发生的.应该说没有浪费时间,如果有浪费时间也可以从整个数据库尺寸的减小上得到好处. 我做过一个程序使用压缩算法来压缩我的二进制字段,效果不错.该压缩控件的输入输出接口使用流. 该控件地址为:http://vcl.vclxx.com/DELPHI/D32FREE/TLZRW1.ZIP 说明:提供 LZRW1/KH 或 LZH 算法数据压缩解压缩的构件 ( 2.01.00 版,附源码 ),作者: Danny Heijl
P pegasus Unregistered / Unconfirmed GUEST, unregistred user! 1999-07-27 #5 用现有的工具一般是对整个数据库文件做透明的压缩,优点是程序不用做任何修 改,压缩效率也比较高。缺点就是访问数据库的效率较低,例如:您想访问第 1000条记录,因为原始数据库文件被压缩了,您可能被迫读了前面的999条记录 才能够读第1000条记录(当然您的程序不知道)。不过倒不一定像wangkun朋友 说的那样需要临时空间:试过DblSpace或者NTFS的压缩属性么? 自己做压缩是比较好的,顺便还可以加密等等,
用现有的工具一般是对整个数据库文件做透明的压缩,优点是程序不用做任何修 改,压缩效率也比较高。缺点就是访问数据库的效率较低,例如:您想访问第 1000条记录,因为原始数据库文件被压缩了,您可能被迫读了前面的999条记录 才能够读第1000条记录(当然您的程序不知道)。不过倒不一定像wangkun朋友 说的那样需要临时空间:试过DblSpace或者NTFS的压缩属性么? 自己做压缩是比较好的,顺便还可以加密等等,
T tqz Unregistered / Unconfirmed GUEST, unregistred user! 1999-07-27 #6 >如果使用压缩控件,可以对数据库中的备注字段等等字段在读出时解压缩,在写入前压 >缩,这样压缩还原的执行是按需发生的.应该说没有浪费时间,如果有浪费时间也可以 >从整个数据库尺寸的减小上得到好处. 这个方法我以前用过的,用Delphi 3自带的压缩流控件。不过还是要在时间和空间之 间权衡。
>如果使用压缩控件,可以对数据库中的备注字段等等字段在读出时解压缩,在写入前压 >缩,这样压缩还原的执行是按需发生的.应该说没有浪费时间,如果有浪费时间也可以 >从整个数据库尺寸的减小上得到好处. 这个方法我以前用过的,用Delphi 3自带的压缩流控件。不过还是要在时间和空间之 间权衡。
W wangkun Unregistered / Unconfirmed GUEST, unregistred user! 1999-07-27 #7 >用现有的工具一般是对整个数据库文件做透明的压缩, >优点是程序不用做任何修改,压缩效率也比较高。 >缺点就是访问数据库的效率较低, >例如:您想访问第1000条记录, >因为原始数据库文件被压缩了, >您可能被迫读了前面的999条记录才能够读第1000条记录 >(当然您的程序不知道)。 >不过倒不一定像wangkun朋友说的那样需要临时空间: 请pegasus 解释一下具体的做法? 如果不把整个数据库解压缩成一个具有特定格式的数据库文件, 如何使用Table,or Query 去访问此数据库文件,难道数据库驱动程序 认得压缩的数据库文件吗? 当然如果使用DblSpace等等实现,因该说是操作系统的功能,不应该算工具了吧?
>用现有的工具一般是对整个数据库文件做透明的压缩, >优点是程序不用做任何修改,压缩效率也比较高。 >缺点就是访问数据库的效率较低, >例如:您想访问第1000条记录, >因为原始数据库文件被压缩了, >您可能被迫读了前面的999条记录才能够读第1000条记录 >(当然您的程序不知道)。 >不过倒不一定像wangkun朋友说的那样需要临时空间: 请pegasus 解释一下具体的做法? 如果不把整个数据库解压缩成一个具有特定格式的数据库文件, 如何使用Table,or Query 去访问此数据库文件,难道数据库驱动程序 认得压缩的数据库文件吗? 当然如果使用DblSpace等等实现,因该说是操作系统的功能,不应该算工具了吧?
P pegasus Unregistered / Unconfirmed GUEST, unregistred user! 1999-07-27 #8 对, 我说的工具就是系统级的工具,例如FreeSpace, ZipMagic等等
T tqz Unregistered / Unconfirmed GUEST, unregistred user! 1999-07-27 #10 >对, 我说的工具就是系统级的工具,例如FreeSpace, ZipMagic等等 还是NTFS好啊
W wuyi Unregistered / Unconfirmed GUEST, unregistred user! 1999-07-27 #11 不知你用的是什么数据库,印象中ORACLE在存放数据时是压缩存放的,不知是否 正确,请各位指教。