很多人都说数据库插入图片不好，趁着下岗的机会我在家里做了个试验插入了1500张图片，没觉得慢

数据库文件50M，图片数量1500个，每张图片大小在200KB至300KB之间，由于like语句的bug问题，改用instr绕过了日语的查询报错，感觉没慢到哪去。电脑是奔腾II+32M内存+win98操作系统





现在还需再插入2000张图片左右，不知道ACCESS还有多少扩展空间，我的想法是先放3000张图片，如果没感觉有什么问题，我就连图标也加上去，图标大约有6000多个，是NDS游戏的图标。

13 个解决方案

#1

电脑是奔腾II+32M内存+win98操作系统 ？？？

楼主，你ＮＢ…………

#2

胡扯，你这是Windows 2000+的系统。

#3

不错，这应该是Win2K或更高版本的“经典配色方案”。

Windows 98，系统默认配色方案下，滚动条、标签背景、按钮表面等“立体对象”的颜色是 &HC0C0C0 。
楼主贴的这张图，滚动条、标签背景，窗体的背景，都是 &HC8D0D4 ，跟Win2K或更高版本的“经典配色方案”一致。

#4

大家重点偏移了，我只是为了探讨access的极限就用一台 能上网的电脑截个图说明一下。我还有个类似的程序加载3000+个游戏在PII电脑上都是两秒钟的事。

















我的老伙伴们还在蜂窝煤，用个win98无需惊动档*。

#5

#6

几千个图片一点都不多。你设想下csdn，每天注册的用户数万个，上传的图片数十万张，图片被显示的次数，数亿次。

#7

快和慢都是相对的。

应用设计的要点是充分满足需求。如果在特定条件下，你认为可以满足需要，将图片插入数据库也并非不可以。

我曾经在数年前做过一个应用，图片较大（一般是照片），就将图片另存于一个特定文件夹下。当时机器内存也小，照片存入数据库的话，查询引起大量的磁盘交换，相当慢。

此外，写应用要考虑到用户可能使用的最差机器环境。如果一个程序仅仅是自己的机器上用，当然就简单得多。

#8

楼主试过远程读写没有？
如果数据库是在远程，那么查询的时候，要把所有查询到的结果都下载到本地后才能返回给调用者
所以有人觉得在数据库查询图片会觉得慢

这个可不像浏览器浏览图片那么简单，浏览器根据 socket 通讯，可以边下载边处理
而数据库是全部下载下来后再返回的

#9

数据库的存取效率本来就比文件系统高，只是存在数据库不能直接看，需要相应的软件

#10

图片存到数据库,量少情况下以及用户少甚至ACCESS一样单用户,单机等情况下一般还好.

说有性能问题,主要是数量多以及多用户外加网络使用情况下的问题,如果你遇到过,就不会有此一帖的了.

只做单机单用户的话硬盘IO一般还是足够的,只要图片不要太多.

#11

我现在也是把图片放到数据库，之前是把截取的图导出BMP再文件流到数据库，发现远程读取时有点慢，后来先压缩成JPG，再存入和导出，可以速度快好几倍

#12

楼主能否把代码贴出来，以飨读者。也让俺学习学习

#13

本地存储、数量不大，外加访问量不高，再加上索引，应该不会很慢。

但是几万条，外加访问量大的话，肯定会很卡的。不信试试吧。