【问题标题】:Is storing image paths in a database necessary?是否需要将图像路径存储在数据库中?
【发布时间】:2009-07-12 01:05:29
【问题描述】:

首先,我注意到有很多关于此的问题,很多都标记为重复。

我最终来到this one

该问题的公认答案虽然部分解决了我的问题,但并没有回答所有问题。

我的问题是,用户上传了一张图片。我将路径存储在数据库中,将图像文件存储在文件系统中。 但是,我制作了该图像的 3 个副本(大、中和小尺寸)。所以总而言之,我有 4 张图片 - 原始、大、中、小。

我是否应该将所有 4 条路径都存储在数据库中,像这样

ID  |      original      |    large        |    medium       |    small       |
----+--------------------+-----------------+-----------------+----------------+
 1  |  /path/to/original | /path/to/large/ | /path/to/medium | /path/to/small |

或者只存储原始路径,并给其他 3 个命名约定,如下所示: car.jpg, car.jpg, large-car.jpg, medium-car.jpg, small-car.jpg?

我觉得这种方式对数据库的负担会减轻,而且如果以后我想添加另一个大小(即超小),我就不必修改数据库了。

【问题讨论】:

    标签: php mysql storage


    【解决方案1】:

    如果给定行中的所有图像都位于同一个位置,我会说它们的基本路径应该是它自己的列(而不是一直从原始图像的完整路径重新派生基本路径)。

    如果数据库中的所有图片都在同一个地方,根本就不要在这个表中存储基本路径;将它放在代码中,或者放在全局配置表中。

    【讨论】:

    • 嗯,这是一个博客。每个用户都有他/她自己的目录。每次用户使用图片创建博客时,我都会使用 blogID 创建一个新目录,并在该目录中存储所有 4 张图片。
    • 那么我要做的是为所有这些目录的父级设置一个常量define('BLOG_IMAGE_BASE_PATH', '/images/go/here') 或其他任何东西,理想情况下,还有一个用户对象上的方法function getImagePath() { return BLOG_IMAGE_BASE_PATH . '/' . $this->blogID; },并组装图像路径从那。
    【解决方案2】:

    似乎您正试图过度使用数据库。这个方法怎么样。

    ImageID  | UserID  | name.. 
    ---------+---------+-----
    1        | 495     | car454.jpg
    2        | 495     | house.jpg
    3        | 44      | kittysmall.jpg
    

    并将所有图像存储在一个地方。

    IMAGES_PATH = "/path/to/images"

    并通过imageID(自动增量)命名图像,因此对于第5张图像,它将是5.ori.jpg或5.large.jpg等

    这样您可以轻松查看谁拥有什么图像,并且用户可以上传具有相同文件名的不同图像而不必担心。

    【讨论】:

    • 有趣。但是这种方法实际上不会过度使用数据库吗?我的意思是,对于每张上传的图片,它都会进行 4 次插入交易。如果用户上传“car.jpg”,我会将其调整为大、中、小。因此我会在数据库中插入 car.jpg、small-car.jpg、large-car.jpg 和 medium-car.jpg;与仅插入“car.jpg”相反,当想要在博客中显示所有 4 张图像时,我只需将“small-”、“large-”、“medium-”附加到原始图像名称(car.jpg )
    • 没有天琴座,你仍然只使用一个插入。您将插入“car.jpg”并选择自动递增的 ID 作为结果,假设它返回“5”。然后保存“5-small.jpg”、“5-medium.jpg”和“5-large.jpg”。
    【解决方案3】:

    对于原始图像的各种大小,肯定有一个可靠的命名约定,这将帮助您生成已知的缓存键,以便您可以将图像存储在一些缓存中,例如内存缓存,这减轻了数据库和服务器的负载磁盘 i/o

    【讨论】:

      【解决方案4】:

      概括地说,如果您可以重新创建信息(因为基数始终相同,后跟用户名),请不要将其存储在数据库中。如果您以后想更改存储图像的目录,无论出于何种原因,您都会遇到麻烦。

      【讨论】:

        【解决方案5】:

        如果特定路径除了文件名之外是一致的,为什么不使用路径常量,然后将不同大小的图像存储在适当的目录中,并仅引用数据库中的文件名。

        这里的主要原则是避免在数据库和代码中出现重复信息。对于数据库,您实现更高的范式,对于您实现 DRY(不要重复自己)的代码。

        假设你的结构类似于

        /home/user/site/images/original/

        /home/user/site/images/small/

        /home/user/site/images/medium/

        /home/user/site/images/large/

        您可以为该信息使用常量。例如

        PATH_ORIGINAL = /home/user/site/images/original/

        PATH_SMALL = /home/user/site/images/small/

        PATH_MEDIUM = /home/user/site/images/medium/

        PATH_LARGE = /home/user/site/images/large/

        然后在你的代码中你可以做类似的事情

        小型车 = PATH_TO_SMALL 。汽车.jpg;

        或者只是在任何查询输出中插入适当的常量变量来加载图像。

        额外的好处是,如果您需要调整目录结构或在服务器之间移动代码,您可以在一个地方更改路径,而不是更新整个数据库记录,这可能会带来更多问题和错误。

        【讨论】:

        • 图片可以这样覆盖,不是吗?
        • 无论脚本正在编写或创建原件(我假设来自文件上传过程),都让图像文件将权限设置为只读一次。这应该可以保护您免受覆盖。但是,您将不得不错误处理任何写入只读文件的尝试。另一种常见的技术是在保存之前在文件名的开头添加一个唯一的哈希字符串。这样,所有新文件都保证是唯一的名称。但也许我误解了你问题的初衷。
        【解决方案6】:

        作为一个小调整,我很想将生成的缩略图等放在不同的路径中(例如:../generated/),以确保在有人上传文件时不会覆盖源图像称为“car-large.jpg”等。

        【讨论】:

        • 好吧,如果有人上传了一个名为“large-car.jpg”的文件,“large-”会被添加到前面,它会变成“large-large-car.jpg”。
        猜你喜欢
        • 2013-04-03
        • 1970-01-01
        • 1970-01-01
        • 1970-01-01
        • 1970-01-01
        • 1970-01-01
        • 2020-11-15
        • 2013-01-12
        • 2015-02-14
        相关资源
        最近更新 更多