Question

假设以下数据库条目..

ID  Name          Slug
--------------------------
1   My Brand      my-brand

..存储我的品牌徽标和/或其他类似图像是个好主意吗？

/img/logos/my-brand-50x50.png
/img/logos/my-brand-100x100.png
/img/screenshots/my-brand-800x600.png

目前的想法是：

赞成

消除额外的数据库列/表。
允许以后随时添加其他尺寸。

CONS

要求PHP检查每个请求上是否存在请求的图像。如果是，请加载它，如果没有，请检查相似的大小，如果没有，请加载默认占位符。

选项

每次都使用/{image_type}/{slug}-XxY.png +检查文件。
在父元素上使用/{image_type}/{slug}-XxY.png + CSS background-image + set占位符背景。在不存在的图像上忽略404，而是让占位符显示。
使用其他数据库列。
使用单独的图像表。

处理此问题的可接受方法是什么？我错过了其他一些明显的，更好的方法吗？

Answer 1

所有这些都与速度，容量和可扩展性有关。

快速解决方案（对客户来说很快）就像您已经提到过的那样：存储不同大小的单独文件。事实是：

它很快（因为文件存在于文件中）
难以扩展（如果我需要尺寸404x404我需要添加新图像，如果我需要1337x1337我需要再次添加新图像）
存储所有图像需要很大的空间

容量感知解决方案正好相反。我们按照所需比例存储一张大图像，并根据需要进行缩放。

例如，我们只能有一个文件：my-brand-2000x2000.png。如果用户（或其他）需要my-brand-405x405.png或my-brand-1337x1337.png我们可以my-brand-2000x2000.png，请缩放并显示它。事实是：

它很慢（因为我们计算每个请求的图像）
它完全可扩展（我们可以从一个2000x2000图像中导出1x1,2x2,3x3，...，2000x2000图像）
存储这几张图片需要的空间最小

理想的解决方案是混合上面提到的这两个。我们按照所需的比例存储一个大图像，并根据需要进行缩放。但是，这次我们还会尝试缓存我们经常缩放的大小。

例如，假设我们有三种类型的用户：总是希望拥有my-brand-404x404.png的失去的用户，总是希望拥有my-brand-1337x1337.png的精英用户和总是希望拥有{{1}的撒旦用户}}。我们仅存储my-brand-666x666.png并将其缩放为三种尺寸之一。几天后我们查看统计数据，我们看到我们生成的1000个请求如下：

my-brand-2000x2000.png 2次
my-brand-666x666.png 499次
my-brand-404x404.png 499次

现在很明显我们应该缓存最后两个，不应该缓存666x666。

关于解决方案的事实是：

由于缓存
它仍然具有能力感知解决方案的可扩展性
它比快速解决方案消耗更少的空间

实施并不难。例如，您可以在PHP中使用GD。我建议不要将图像存储在文件系统中而是存储在数据库中。那么你就是独立于文件系统，也是技术独立的。访问图像的方式可能如下：my-brand-1337x1337.png。 image.php?brand=my-brand&w=1337&h=1337应解释参数，在数据库或缓存中查找图像，如果没有，则：scale，update statistics和display。

以下是动态图片的示例，尝试更改参数：http://www.cs.put.poznan.pl/adanilecki/create_img.php?text=Hi%20there

为一个数据库条目存储多个大小的多个图像

赞成

CONS

选项

1 个答案: