有经验的人请进:请问保存图纸的方法,大约有10万张以上的图纸,请问用什么方法保存最好?图纸的大小最大3m,一般都是几百k,我用的是sql数据库!我试过用数据库保

  • 主题发起人 主题发起人 guan1573
  • 开始时间 开始时间
G

guan1573

Unregistered / Unconfirmed
GUEST, unregistred user!
有经验的人请进:请问保存图纸的方法,大约有10万张以上的图纸,请问用什么方法保存最好?图纸的大小最大3m,一般都是几百k,我用的是sql数据库!我试过用数据库保存,不行,那样数据库太大了,那样会减慢操作数据库的速度(100分)<br />有经验的人请进:请问保存图纸的方法,大约有10万张以上的图纸,
请问用什么方法保存最好?图纸的大小最大3m,一般都是几百k,
我用的是sql数据库!
我试过用数据库保存,不行,那样数据库太大了,那样会减慢操作数据库的速度
 
使用Oracle数据库的分区表,也只能用这种方法好一点
要不用目录结构,给目录一个结构,然后存相应的文件
 
只有用Oracle 了,在这方面还没有什么数据库比得上
 
天哪,我不能改变数据库,只能用sql,如果我用数据库保存会有什么问题,
给我点建议,或者还有什么好的办法?
 
可以保存路径,(只要你不在改路径的话)
要是保存到数据库中oracle还是第一的选择

 
帮我想想,还有什么办法?
我用的是sql,不能用别的了?
555555555555~~~~~~~~~~~~~~~~
 
压缩图像
 
找个保存根路径的方式
数据库中保存文件相对路径
这样可以解决文件迁移
 
做成flash,文件很小,最好不要存到数据库里
现在一汽大众的零件图样都是做成FLASH
 
最好还是对图纸采用压缩还原算法,这方面的控件和资料很多的
流程:
图纸--->压缩------>入库------>解压还原------>图纸


 
图纸不入数据库,有泄密的危险,我这里有惨痛的教训。
 
应该用数据库 如果是sql server,10万张图纸不会慢 可能和你用的前端工具编写的方法有关
关键是你的 前端工具取数时不要选中图纸的那个字段 更不要 select * 那样就慢了 select
的字段越少越好 当察看某张图纸时才去取 注意只要取一张的
 
那就是入用sql数据库来保存了,那样我得数据库会非常大,即使我将文件先压缩再保存,

我做过测试,我用100条记录将大小为:1M的的文件100个,保存到数据库中,最后数据库
长大了:100*1M

如果有100000个1M的文件保存到数据库中,那不是数据库是10G吗,
我要保存的文件恐怕还会更多,10万是保守数字,请问如果我选择用数据库保存会不会有什么问题呢?我用的是sql。
 
我用过通过ftp保存到指定的路径下,但是有一定的缺陷:
1,ftp不稳定(大缺陷)。
2,文件保密性差。
3,不利于程序维护,比如数据库备份的同时,也要备份文件,备份文件经常会出错。
有用ftp的同行,如果你处理的很好,可不可以跟我说说你的思路?
谢谢各位同僚!
 
to guan1573:你的测试算法100*1M也太天真了吧 哈哈 是不是100个1k的就只占一兆呢?
还有你管它长多大 那是它本身的需要 并非大就是慢
难道你心疼买硬盘的钱???

 
你才天真呢!
到时我得数据库10G大,难道不会出问题吗?
 
先对图纸分类,然后分到不同的库中
不管用什么方法10G的空间还是要的,毕竟有10万张图
不放在同一个库中出了问题损失也会降低!
 
这个问题我以前也遇到过,正如大家说的:
一种就是将图纸数据保存到数据库里,这方面oracle很不错,
这样的话,数据量大的话,数据库会很大,虽然可以压缩存储,但还是不会很小,
不过数据库大了,对数据库的操作速度的影响肯定会有的,但不会成倍的增长,我
想,前端的程序的效率高低,倒是对数据库的运转影响很大,SQL server对这样大
的数据库还是可以应付的。
另一种就是将图纸用文件的形式保存,然后再数据库里保存它的路径,
yoking说的先保存根路径,数据库中保存相对路径的方法挺好的,不过这虽然
可以解决数据库大小的问题,但正如大家说的那样让也存在很多的弊端。
至于用什么方法的话,应该还是考虑系统的实际情况来确定。
 
在数据库服务器上建立一个有共享写权限的文件夹PicShare,然后在保存图片时用下列路径
服务器IP地址+'//'+'*.jpg'的方式来保存,并将该存取路径保存到数据库中作为一条记录;
提取图片时与此类似。
 

Similar threads

S
回复
0
查看
3K
SUNSTONE的Delphi笔记
S
S
回复
0
查看
2K
SUNSTONE的Delphi笔记
S
S
回复
0
查看
1K
SUNSTONE的Delphi笔记
S
后退
顶部