对于少量用户写信息，大量用户都是在看信息的网站：例如CMS系统，编辑发咨询，用户看，例如中小企业产品发布网站。 对于这类需求我们可以把文件专门放到一个目录下，例如放到网站根目录的upload目录下，然后按天建文件夹，将每天的文件放到一个目录下，文件名可采用数字生成。例如：upload/20100612/1224455.jpg；通常的情况下这种目录结构就可以保证每个目录下不会有太多的文件。

对于博客，论坛应用，需要对每个用户分配文件存储空间，如果有需求的话还要限制用户的存储空间，对于一般规模的网站目录结构可以用用户id+日期的形式；例如upload/234/20100612/abc.jpg。如果规模较大，可以将文件分布到几台不同的服务器上，可以根据用户id制定一个分布的规则，每台服务器用不同的域名，并在数据库中存储文件的完整url地址，这种情况下的路径结构通常是：http://file1.abc.com/upload/234/20100612/abc.jpg。

我曾经观察过微软的文件下载文件存储的路径结构，他是用guid生成的一个路径，例如：http://download.microsoft.com/download/5/6/7/567758a3-759e-473e-bf8f-52154438565a/dotnetfx.exe ；它这个结构目录是guid的前三位和guid做了一个4级的目录，这种情况下，就保证了，每个目录下不会有很多目录，因为是guid所以每一个文件都放到一个单一的目录下了，这种结构对于做下载的网站应该是一种不错的选择。

还有web2.0的网站会涉及到用户头像的存储，头像的存储比较特殊，一个用户固定有那么几个尺寸的图片，我们分析一下开心网和sina的头像地址，看他们是如何做的存储
1. 开心网的存储，如下是两对链接地址，每对中的第一个是头像地址，第二个是用户首页，首页中的参数是用户id

http://pic1.kaixin001.com.cn/logo/13/39/50_133973_82.jpg

http:///face/u40200.png

很简单直观应该是放到了一个目录下，直接用户id做的文件名，没有分目录结构，这样在文件夹中文件过多时是否会引起性能问题呢？