Хранить ли названия изображений в БД?

Question

[Anchor00]

В скрипте каталога изображения товаров именуются по маске {id}{alias}{№}.{ext}. Возникает вопрос, стоит ли вообще делать поле в таблице products для изображений? (они ведь именуются по строгому шаблону) Какие могут быть подводные камни/нюансы.

UPD. Парни, есть важный нюанс - это коробочный скрипт

Answer 1

[Alexander Litvinenko]

Нет, это все-таки очень желательно. то что я опишу не единственно верная реализация, но достаточно удобная.

У вас будет много картинок как я понял, также вероятно у вас будут сохранены разные размеры загруженной картинки, и возможно различные варианты с наложенными эффектами.

Также в папке не может быть много файлов, есть некоторые особенности файловой системы, много картинок в одной папке - замедлит ее работу.

Допустим картинка называется 123.png и ее хеш e621fccb4c38d568669432b004a50f59.
Вы можете сделать путь к картинке
/img/621/fcc/b4c/38d568669432b004a50f59/original.png

Что даст?
1. Название картинки берется с бд, если зальют две одинаковые картинки, их хеш совпадет, вы избежите дублирования файлов.
2. Вы можете сохранять разные варианты картинки, например:
/img/621/fcc/b4c/38d568669432b004a50f59/original.png - это оригинал, а
/img/621/fcc/b4c/38d568669432b004a50f59/size_l.png - уменьшенная копия
/img/621/fcc/b4c/38d568669432b004a50f59/size_l_stamp.png - уменьшенная копия + водяной знак
3. В папке никогда не будет больше 4096 файлов, так как название папки это часть хеша

Comments

[Anchor00]

Очень важное замечание! Благодарю. Посмотрел в Магенто, тоже почти также сделано. Только они разбивая на подпапки, позволяют оставить оригинальное имя файла c2n.me/3nDTIK4 , не обязательно хеш. А вы называете ТОЛЬКО хешем? Или все же позволяете путь представить в виде имени файла?

[Saboteur]

Anchor00: как я понимаю, именуя файл его хешом, сразу на этом уровне убираются дубликаты без всяких дополнительных проверок.

[Arris]

Следует отметить, что у двух одинаковых визуально картинок может быть разный EXIF, а значит разный хэш.

[Arris]

Anchor00: а вы отдавайте картинку скриптом, а не напрямую. Тогда имя будете отдавать какое записано в базе, не такое, как она лежит на диске.

[Anchor00]

Alexander Litvinenko : Александр, у меня пара вопросов, если Вас не затруднит=)))
1. Как считываете хэш? (Не так случайно habrahabr.ru/post/120562 ? Как понял Вы берете хэш не названия а самого изображения, и как понял, есть много способов это сделать)
2. Нет ли проблем при Импорте большого кол-ва товаров, когда кол-во изображений, очень велико?
3. Могут возникнуть сложности синхронизации с ERP/другими сервисами. Не сталкивались ли с этим? Например если нужно провести синхронизацию со стороны сервера (где хранятся хэши). То при удалении на сервере изображений(с хэш-названиями), чтобы найти их сопоставленные файлы у другой проги, нужно на ней сначала, считать хэши у всех изображений (что может стать ресурсозатратным, и проблемным при большом кол-ве изображений).

[Anchor00]

Alexander Litvinenko : Я сам склоняюсь к такому варианту.

Дробиться {alias}, последняя папка имеет в названии {id}. Что довольно удобно, появляется "папка товара"
my/al/ias_id17/{№}.{ext}

Кумекаю вот только, не возникнет ли проблем с синхронизацией с внешними ситемами (erp, и пр.)

[Alexander Litvinenko]

Anchor00: да, примерно так. Что до id, как имя папки, это теже яйца, только в профиль.
Путь по ид вычислять сложнее, так как длина строки разная, а хеш мне достаточно разделить строку по 3 буквы. Также айди не видит дубликаты файлов.

[Anchor00]

Alexander Litvinenko Александр, а не возникало ли проблем при синхронизации с внешними сервисами, (ERP, yml, и пр) и с быстродействием (ведь считывание хеша у большого кол-ва картинок может оказаться дорогой операцией, насколько я понимаю) ?

[Alexander Litvinenko]

Anchor00: Синхронизация это другой вопрос. Синхронизация с другой системой, это само по себе уже задача, в независимости насколько схож внутренний формат хранения. Что до считывания хешей, вы делаете это только один раз и только для новых файлов.

Answer 2

[Радость моя]

Нет не обязательно, если всегда следовать этому шаблону, нет необходимости хранить адрес в бд. Даже если Вы захотите переделать шаблон, или алгоритм хранения вообще, зная первоначальную маску Вы и с этим справитесь. У меня тоже на сайте храняться изображения к объявлениям, по названию папки с id самого объявления. И база об этом не знает. И не надо ей лишних 20-30 символов хранить (особенно ощутимо если индексы, и если данных более 1.6млн записей).

Answer 3

[Alejandro Esquire]

Вообще насколько бы всё было проще, если хранить изображажения во внешних файлах, с именами {id}.{ext}, если бы одному объекту базы мог соответствовать только одно изображение. Базу вообще можно было бы не увеличивать ни на байт. А оно может соответствовать одно, если {ext} принять равным pdf, и разные изображения помещались бы просто на разные страницы pdf. И удобная операторская работа с изображениями реализовывалась бы простой перегенерацией pdf из постраничных графических файлов. Я пошел по этому пути, но у меня специфика просто Электронного Архива. Наверное вовсе ничего общего с решаемой вами задачей....