用户照片库的MySQL设计

3

我正在为一个基本的照片库设计数据库,每个用户可以上传多张图片。

目前,这是我的设计:

photo_gallery

photo_id -    image             - sort_order - user_id
1        -    test.jpg          - 1          - 1
2        -    another_photo.jpg - 2          - 1

然后,在我的文件夹结构中,我会创建一个新的文件夹,例如:images/photo-gallery/,并将图像存储在其中。现在,我应该为每个用户ID创建一个文件夹,并将他们特定的图像存储在那个文件夹里吗?
所以在这种情况下:images/photo-gallery/1/test.jpg,所有用户1的照片都会在那里?
另外,对于重新调整大小,我考虑使用smart image resizer,这样我就可以只存储原始照片,如果我想将其调整为特定大小,我只需使用类似于/image.php?width=200&height=200&image=test.jpg的脚本调用它。
我应该对这些文件名进行哈希处理吗?我有遗漏什么吗?您有任何改进建议吗?
谢谢!
2个回答

4
现在,我应该为每个用户ID创建一个文件夹,将他们特定的图像存储在该文件夹中吗?
是的,最好以某种方式分隔上传文件,以免一目录持有成千上万个文件。您可以按用户ID、首字母(例如images/t/te/test.jpg)或哈希值(例如images/0e/0e4fab12.jpg)进行分隔。
是否应对这些文件名进行哈希处理取决于您想要实现什么目标。由于您计划在URL中引用文件名,因此使用已知的“安全”字符集存储文件名可能是一种优势。
image.php?image=c/ca/cat%20farting%20On%20a%20lemon.jpg
 -- vs --
image.php?image=0a/0a1b2c3d.jpg

如果您这样做,我建议扩展您的数据库模式以包括原始文件名:
photo_id | image           | orig_fn           | sort_order | user_id
1        | 0a/0a1b2c3d.jpg | charginLazors.jpg | 1          | 2

您还可以考虑存储有关图像的其他元数据,例如上传日期、标题等。


关于文件夹结构,您可以使用文件名中的任意数量的字符,但需要考虑以下几点:

使用创建十六进制文件名的哈希方法意味着您的子文件夹最大数量将是16的倍数:

  • 一个字符 - 16个子文件夹
  • 两个字符 - 256个子文件夹
  • 三个字符 - 4096个子文件夹

如果您使用超过两个字符,建议进一步嵌套文件夹:0a/0a12/0a12bd31.jpg0a/12/0a12bd31.jpg。这样可以使文件的导航/管理更加可控(在我看来)

请记住,您使用的前缀字符越多,每个文件夹中的文件就越少。如果您预计会有大量文件,请选择更多文件夹,并使每个文件夹中的文件较少。


这是一个好答案。我只想强调文件名/路径重复的可能性。如果存在用户上传相同名称的图像的可能性,或者用户会上传相同的图像(在您基于图像本身的哈希值生成文件名的情况下),则需要确保首先检查重复项(file_exists()),并以某种方式处理它。您还可以将mysql photo_id附加到文件末尾('_'.photo_id)以使其保持唯一,并可能将其用作将来识别的快捷方式。 - Ben D
感谢您的出色回答。我有几个问题。为了存储路径,最好将其存储为0a/0a1b2c3d.jpg而不是包括图像文件夹,以防将来发生更改。此外,在这种情况下,存储原始文件名有什么好处? - Drew
@Drew:很好的发现。是的,最好将图像路径相对于图像根路径(您可能在配置文件中设置)存储在数据库中。我会修改答案。关于原始文件名,这实际上取决于画廊的目的。如果用户查看图像的原始文件名(或者使用原始名称而不是似乎随机的名称下载图像)有用,则包括它。如果文件名无关紧要,请跳过它。这就是构建自己的系统的美妙之处:您可以使其完全适合您的预期用途。 - Justin ᚅᚔᚈᚄᚒᚔ
好的,太棒了,谢谢!最后一个问题。我想创建一个PHP脚本,将文件重命名为哈希,并自动获取前两个字母并创建一个文件夹(如果不存在)。但是,如果它是随机生成的,每个文件都有与先前文件相同的2个字母的可能性很小,那么会不会有很多文件夹呢?还是我误解了什么? - Drew
是的,您将在上传处理程序中生成哈希,在图像路径上创建任何必要的文件夹,然后使用move_uploaded_file()将其放置在具有散列文件名的最终位置。我还使用更好的文件夹结构可能性更新了答案的解释。 - Justin ᚅᚔᚈᚄᚒᚔ
谢谢解释。是的,我不指望有很多图片,最多几百张。所以我认为不需要再嵌套文件夹了。 - Drew

0
现在,我应该为每个用户ID创建一个文件夹吗?
这是一个相当不错的解决方案,另一个可能性是根据目标照片数量每年创建一个文件夹,最终根据需要再按月份创建。对于照片文件名,我建议使用数据库ID,这将避免字符编码问题,并最终保留数据库中的原始名称。
此外,对于重新调整大小,我考虑使用智能图像调整器。
在我看来,除非您需要保留全尺寸图像,否则建议存储调整大小后的照片。好处如下:您可以存储更多照片,可以更快地发送照片,照片导航将更加灵敏。
我还漏掉了其他什么吗?
也许是用户权限类型,这可能会影响您存储图像的方式。
有关如何改进此内容的任何建议吗?
我已经研究了这些想法,并创建了一个名为“PhotoBlog”的开源项目,您可以在其中查看PHP和JavaScript源代码。

网页内容由stack overflow 提供, 点击上面的
可以查看英文原文,
原文链接