我正在用PHP实现一个图像上传系统，需要以下内容：
- 有类别
- 允许用户对图像发表评论
- 允许对图像进行评级
为此，我有两种方法：
1.实现按文件夹分类
每个类别都有自己的文件夹，PHP将通过这些文件夹检测类别。
优点
- 结构化外观，易于定位的图像
- 使用本机PHP函数来操作和收集有关文件夹和文件的信息
Cons
- 多分类是一种痛苦
- 需要在数据库中保存完整路径
2.实现数据库分类
数据库中的每个图像都将有一个catID（或多个catID），PHP将查询数据库以获得图像
优点
- 易于实现的多类别
- 仅保存图像名称
Cons
- 看起来更乱
- 需要大量查询数据库
你认为哪个更好？还是我缺少了第三种完全不同的方法？
请注意，我不需要代码，我可以自己实现，我正在寻找要实现的内容。
很想听听你的消息。
我认为第二个选项更好，DB给了你更多的灵活性，我认为如果你设置了正确的索引，性能会比文件系统更好
在文件系统方法中，每个映像只能有一个类别，在数据库中，您可以在一个映像上设置多个类别
Db更乱的问题，对不起，我在数据库中找不到原因，它会更乱，也许你的意思是文件没有在文件系统上组织，但你仍然需要在文件系统中组织文件，并将它们划分到多个文件夹以获得更好的性能，如果你想获得所有上传的图像，你可以在数据库中查询所有图像，这将比所有类别文件夹上的ls快得多
在使用DB方法组织文件系统中的文件时，我的意思是你需要将它们划分为几个文件夹，实际上这取决于你如何预测图像的上传：
- 如果你预测上传将在很长一段时间内传播，那么我认为最好按时间（天、周、月）将文件放在每个范围的目录中。例如，如果我现在上传一个图像，它将转到"/web_path/uploadd_photos/week4_2012/[some_generated_string].jpg"
- 如果你不知道如何预测上传，那么我建议你将文件分为一些通用的文件夹，比如图像名称MD5哈希中的前两个字母，例如，如果我的文件名是"photo_2012.jpg"，则哈希将是"c02d73bb3219be10559ac8e38ebdac2"，因此文件系统中的路径将是"/web_path/upload_photos/c/0/[some_generated_string].jpg"
第二个需要大量查询数据库的问题并不完全正确，因为您需要在文件系统上进行同样数量的查询，而这些查询要慢得多。
祝你好运。
PS不要忘记为已上传的任何图像生成一个新的文件名，这样不同用户上传的同一图像名或同一用户就不会发生冲突。
我倾向于采用数据库方法。您列出了大量查询数据库的需求，但这正是构建数据库的目的。正如您自己指出的，当涉及到属于多个类别的项目时，层次结构有严重的局限性，虽然您可以使用本机PHP函数来导航树，但这真的比运行SQL查询更快或更高效吗？
自然，实际的文件数据需要放在某个地方，而BLOBS委婉地说是有问题的，所以我会将实际的文件存储在文件系统中，但所有关于图像（元数据）的数据最好存储在数据库中。数据库为您提供的额外灵活性是值得的。
第二个解决方案（数据库）实际上是一个TAG/LABEL数据分类系统。这就是前进的道路，最大的例子是Gmail和Stackoverflow。唯一需要注意的是如何对标记建模。若标签未正确规范化，则从数据库进行查询的成本会很高。
仅使用文件夹来确保文件存储的可靠性，每个文件夹存储一定数量的文件，即
/b/e/beach001.jpg
至于你的困境，这根本不是一个问题
根据您的情况，您可以自己说数据库是唯一的解决方案。
由于您需要一个数据库来存储评论和评级，所以您也应该在数据库中存储类别。稍后，您可能还想存储图像标题和描述；数据库允许您这样做。而且我不会经常担心查询数据库。
是将映像本身存储在数据库中还是存储在文件系统中是一个单独的问题，本文将对此进行讨论。
关于在文件系统中存储映像的注意事项：不要在一个目录中存储数千个映像；这可能会导致操作系统的性能问题。相反，发明一种在子目录中组织图像的方法。您可以按日期、文件名、随机等对它们进行分组。一些约定：
上传日期：月/年
/uploaded_images
/2010/01
/2010/02
上传日期：年月
/uploaded_images
/2010-01
/2010-02
图像名称的md5哈希：第一个字符
/uploaded_images
/0/
/1/
.
.
.
/e/
/f/
数千批
/uploaded_images
/00001000/
/00002000/
/00003000/
我最终给出了这个问题的最佳答案：在文件系统上高效地存储用户上传的图像。
它就像一个符咒。感谢所有的答案！