Переделывал сайт заказчику на Netcat и с удивлением обнаружил, что кто-то ещё использует загрузку отдельных картинок для оригиналов и для превьюшек и как следствие отдельные столбцы в таблице БД. Куда ещё не шло создавать превьюшки на стороне сервера после загрузки оригинала.
Идея простая и не новая. C таким подходом я в первые столкнулся в UMI-CMS, а использовал в RubyOnRails. Смысл в том, что превью создаются только когда они нужны и какого угодно размера, а В БД храниться только название оригинала.
Если Вам необходимо вывести превью картинки вы вызываете функцию типа:
Метод view_thumbs проверяет в папке (например "/images/cache") наличие файла originals_name_file_100xauto.jpg. Если находит то возвращает строку «originals_name_file_100xauto.jpg», если не находит, то создаёт файл нужных размеров на лету и возвращает то же самое.
Достоинства подхода очевидны:
Идея простая и не новая. C таким подходом я в первые столкнулся в UMI-CMS, а использовал в RubyOnRails. Смысл в том, что превью создаются только когда они нужны и какого угодно размера, а В БД храниться только название оригинала.
Если Вам необходимо вывести превью картинки вы вызываете функцию типа:
- @thumbs = Photo.view_thumbs('originals_name_file.jpg', '100', 'auto')
где второй и третий параметр это нужный размер в пикселах (auto значит автоматическая подгонка под массштаб). Метод view_thumbs проверяет в папке (например "/images/cache") наличие файла originals_name_file_100xauto.jpg. Если находит то возвращает строку «originals_name_file_100xauto.jpg», если не находит, то создаёт файл нужных размеров на лету и возвращает то же самое.
Достоинства подхода очевидны:
- Не создаётся мусора в виде большого количества превьюшек на диске. Все превью храняться в одной папке «cache» и могут периодически удаляться для освобождения места.
- Неограниченное количество превьюшек разных размеров. Достаточно только задать нужные параметры в методе.