Question

论坛、相册、SNS系统里用户上传的图片是存放在数据库里还是文件系统里更好？

对图片操作没什么概念，是不是都要用HTML的<img>来显示，这样的话似乎是放在文件系统里存取会比较方便，但这么做导致可以通过浏览器地址栏直接获得图片，安全性似乎非常差。（用tomcat的话，不知道是不是可以用web.xml来跳转到WEB-INF下的jsp或servlet，权限验证后在WEB-INF下获取并返回图片。不过我在学GWT，就算这么做可行，也需要考虑怎么整合。）
用数据库保存图片的话，备份会比较完整，但会不会导致存储和存取效率大幅度下降？好像操作上稍微麻烦一些。
不知道那些大网站都是怎么处理图片存储的，除了安全、效率、完整性，还考虑了哪些方面。

Answer 1

一般情况下，把上传的图片存到文件系统里，数据库里存储这张图片的url，以便找到图片位置。给你个建议，上传后的图片给它重命名一下，名字里最好有个随机数，防止图片重名，这是我的一点经验

追问

那么怎么进行权限控制呢？不是每个图片都是给所有人看的。

追答

不是一类的图片你也要存在一起吗？最好一类图片存在一个文件夹里，比如：头像图标存在一个文件夹里，用户上传的文章的相关图片存在另一个文件夹里，相应的多定义几个存储路径，这样不容易乱，也安全

追问

当然会分文件夹。每个用户建一个文件夹？据说有的网站是这么做的。但如果不是放在web-inf下，任何人都可以用浏览器直接通过输入URL来访问，怎么来解决这个问题？

追答

一类图片建一个文件夹，按功能分，如果按用户分就太多了。图片上传位置你可以自己定义。web
-inf是什么？不太清楚，可能是咱俩用的架构不一样吧

Answer 2

文件需要重命名 文件夹层级结构需要仔细规划 同一个文件夹下如果存太多图片 会影响效率 所以一般都是这么搞：
photo/uid/2012/10/xxx_xxxxxxx.jpg 创建规则可以是 uploadsDir/模块名/[用户id/]年/月/随即产生的文件名

因为文件名是理论唯一且杂序的 所以即使你从url输入 也不可能猜到路径 上面的用户id可以考虑不要如果用户太多了也导致你文件夹建的多 但有用户id有个好处是 直接可以算出用户文件占有量不然你还需要去数据库做累计 缩略图命名规则：xxx_xxxxxx.__20x20__.jpg 用程序来算 这样数据库字段只保存一个 其余路径可以推算 。
大型网站 可能会考虑用分布式文件系统 比如fastDfs等 文件有专门服务器的 并且支持apache或者nginx 有扩展可以直接访问到图片 所以数据库只保存fileId（即文件上传后返回的路径）