如何在文件系统上存储照片并在数据库中存储排序顺序

时间:2013-10-01 01:36:40

标签: architecture directory photos

我正在重新设计我的网络应用程序,该应用程序主要来自用户照片。我们的照片量通常为每用户数百万或以上至35。

无论如何我想要做的是重新设计我们如何将照片存储在文件系统上并在数据库中引用它们。我们当前的系统有效,但并非没有缺陷。

目前我将它们存储为

用户数据库表

pk 1 
photo_count 12

最终成为目录

storage/000/000/000/000/001/1_640x480.png

storage/000/000/000/000/001/12_640x480.png

目录源自用户pk

文件名中的第一个数字是排序顺序

文件名是指照片尺寸。

这是将照片存储在数据库中的一种非常有效的方法,但它没有缺陷。每当排序更改时,我们必须首先将更改写入临时目录,然后覆盖主目录中的所有照片,这些照片效率并不高。我们还将照片导出到其他网站,我们当前系统的问题是,如果照片被修改,名称永远不会改变,因此第三方网站永远不会知道从Feed中刷新照片。最后一个主要问题与照片计数与目录计数不同步有关。这导致我们从数据库photo_count生成照片URL,这可能存在也可能不存在,导致某些第三方网站在照片导入作业上失败。

我的目标解决方案是要执行以下操作,但我想要一个专家意见。

user database table
pk "1"
photos "stored as a comma separated list of photo names generated from SHA-1" example: 

f56c0de1c61fdb926e79e8a0a65bd12930c9.jpg,ec1c55bfb660548a6770238668c4b117d92f.jpg

我的想法是将照片排序顺序存储在列表中,因此如果订单发生变化,我只需要重新排列列表而不是重命名照片。

我想我可能会继续从用户pk派生我的目录结构,虽然我更喜欢使用某种哈希,但我不知道如果这是首选方法,如何在数据库中引用它。它只是存储在另一列中吗? 例子

00e4 becomes /00/e4/

我似乎遇到的唯一其他问题是照片尺寸,假设我仍然需要存储缩略图。是否建议使用_thumb.jpg后缀文件名?

我认为这会解决第三方提要,因为每张照片都会获得一个唯一的名称,该名称在修改时始终会更改。

有人对这个问题有专家意见吗?我不确定这是最好的解决方案,所以我想听听别人在做什么。非常感谢。

1 个答案:

答案 0 :(得分:1)

我不确定我是否完全理解了这个问题,但我会描述他们解决相同任务的方式(唯一不同的是我们制作了一个任意文档库)。

主数据库条目是docs table:

Id              -- file id, pk
UserId          -- owner id
Size            -- file size in bytes
FileName        -- name to display like 'img.jpg'
ContentType     -- image/jpg
FileLocation    -- location of the file on filesystem.
                -- in our case it was something like {storage-root}/{userid}/{guid}
ThumbLocation   -- location of a preview version of the same file.
Created         -- upload time

所以上传算法:

  • 从用户处获取文件。
  • 创建符合上表结构的空Document对象。
  • doc.FileName设置为原始文件名(“img.jpg”)。
  • 每个模板的文件系统的Caclulate目标文件夹'/ files / {userid}'。
  • 生成唯一文件名(Guid.New())并将其值保存在doc.FileLocation
  • 将文件写入doc.FileLocation
  • doc.Size设置为原始文件大小。
  • 如果是图片,请生成预览文件,生成名称:doc.ThumbLocation = doc.FileLocation + "thumb"
  • 写拇指文件。
  • doc保存到DB。

当用户请求文件列表时(通过类似/files/{userid}的网址):

  • 从数据库中读取所有用户的文档
  • 请注意,排序选项不受物理文件及其位置的影响。表格中已包含所有必需信息)。
  • 向用户显示文档列表。
  • 每条记录都显示doc.FileNamedoc.Size和指向/files/{userid}/{fileid}的链接

当用户通过/files/{userid}/{fileid})等网址请求文件时:

  • 从数据库中读取文档
  • doc.FileLocation
  • 加载文件
  • 将其发送给用户。

结论是:我们仅在上传时管理物理文件和位置。其余操作仅基于我们放入数据库的数据。然后获取文件内容,我们依赖于写入表格的路径,并且不会打扰它们的确切含义。