我知道这个问题以前被问过很多次,但我还没有找到解决我具体情况的答案。
使用PHP&MySQL。。。
我即将向一个应用程序添加用户档案图片,在我看来,我有几个选项。其中两个如下:
1.不引用数据库中的图像并存储图像就像这样:-
-
/assets/avatars/32px/userid.jpg
-
/assets/avatars/90px/userid.jpg
- /assets/avatars/256px/userid.jpg
这意味着没有额外的数据库查找,因为我已经有了相关的userid。
1.将相对路径存储在users_meta表中,并在检索用户数据时使用联接检索url。
每种方法的优点和缺点是什么?如果在你看来,这两种方法都不是最好的方法,你认为存储/引用和检索用户档案图片的最有效和可扩展的方法是什么。
非常感谢
编辑:添加更多详细信息:
我对选项1的担忧是,我不确定文件系统将如何处理单个目录中的100多万个文件。它会慢到爬行吗?如果是的话,我该如何解决这个问题?有没有一个结构可以消除这个潜在的问题?也许使用用户加入的时间作为url的一部分,并按月存储图像。
例如/assets/avatars/10_2012/small/userid.jpg
10_2012是指2012年10月注册的所有用户。
或者在每个目录中只存储1000个图像,并访问类似的内容:
- /assets/avatars/0/small/userid.jpg
- /assets/avatars/1000/small/userid.jpg
- /assets/avatars/2000/small/userid.jpg
每当应用程序注册用户达到1000*n时,添加一个新目录。
这会带来优势吗?
您可以使用选项1,但使用部分id来创建路径。例如,如果您有六个数字的Id,则可以将前两个数字作为路径的一部分:Id 123456.xyz将变为/1/2/123456.xyz等。。。在本例中,对于数字id,它将限制每个目录包含1000个文件。
正如您正确指出的,如果使用文件系统来满足您的需求,您不必执行额外的数据库查找。这为您节省了时间和资源。
我所看到的使用DB的唯一好处是"单点"备份。但我怀疑它是否是一个非常有效的"专业",或者它是否超过了由DB查找引起的额外间接级别所带来的额外复杂性
编辑(与问题中的编辑相匹配):文件系统的工作方式在很大程度上取决于操作系统。你的目标平台是什么?
我在应用程序中倾向于保存原始图像。
查找后,生成缩略图(或任何大小的图像)并将其放入缓存目录,或者如果图像已经存在于缓存目录中,则将其返回给用户。
如果上传图像的人删除或更新了原始图像,那么您也可以将其从缓存中删除。
这样做非常有用,因为在最初保存时不需要知道图像将使用的每个维度。