Не все типы картинок имеют однозначную сигнатуру, например, bmp не имеет. Поэтому обычно вьюеры ориентируются на параллельно с файлом приходящий content-type , например, image/jpeg , или в крайнем случае на расширение.

Виноват, ляпнул по старой памяти, не проверив. Bmp имеет сигнатуру ВМ. Наверное, я ico имел в виду. Там нули в начале, не очень надежный способ идентификации типа.

Хранить в отдельных полях полезно и content-type, и размер в байтах, и размер в пикселах, и даже хеш файла. Это несколько избыточно, зато потом поиск эффективно можно организовать. Например, ограничить выборку только маленькими (меньше 1MB) картинками типа gif. Даже если сейчас нет такой нужды, когда-нибудь обязательно возникнет. А при наличии хеша можно быстро найти по известной картинке (и более ничего) соответствующую запись.

Кстати, вот весьма полезная задача - найти дубли картинок. Шарашить квадратичным поиском сравнения блобов тяжеловато будет, особенно на емких базах. А если есть хеш и индекс по нему - милое дело.

Dimitry Sibiryakov,

В рассматриваемом мной контексте нет задачи искать "похожесть" картинок, синий цветок на желтом поле или портрет Путина. Для этой цели есть специальные инструменты с ИИ и другими высокими материями. Я говорю лишь о точном совпадении, что практически тоже бывает полезно.

Ну, например, команда дизайнеров и этих, контент-менеджеров, делает сайт, портал даже. Много страниц, много разных картинок, много всего. Каждый в своем углу ковыряется. Все хозяйство лежит в БД. И вот одному э... контент-менеджеру приходит гениальная мысль посадить в свой уголок рыжего котика. Он роется в файлах общей помойки, или даже в интернете, и, ура, находит котика! Засовывает в базу, ставит ссылку, как полагается в их системе. И невдомек ему, что еще вчера коллега засунул в базу точно такого же котика. И теперь в базе 2 котика. А когда начальство - Что еще за хрень?! - прикажет убрать безобразие, удалится только один, а второй будет жить до поры до времени, пока тоже не попадется на глаза.

И то, что э... контент-менеджер один, проблемы не решает. Правая рука часто не знает, что делает левая, особенно когда прошли месяцы и годы.

А так при загрузке небольшая проверка - опаньки, а такой-то файл уже есть! И используется он там-то и там-то. Удобно же.

Тогда таки размер надо держать в отдельном поле. По сути размер - это тот же хеш, только с большой вероятностью конфликтов. Так уж лучше в качестве хеша хороший хеш использовать.

Это да. Красивый же пример, а? А если совсем практически, то там более прозаично. Моя утилитка регулярно забирает с определенного ресурса файлы, в данном случае картинки, и закладывает в БД. Картинки имеют уникальные идентификаторы, и при этом их файлы могут меняться со временем, но могут и не меняться. Так вот, чтобы избежать лишних апдейтов и многомегабайтных пересылок, утилита сперва запрашивает у базы атрибуты образа, в том числе хеш, сравнивает их на стороне клиента с новыми атрибутами, в том числе хешем, и делает обновление только в случае расхождений, при этом обновляет только нужное.

До поиска еще дело не дошло, но что-то мне подсказывает, что не за горами и поиск.


Согласен. Проблема лишь в определении фигни.