Хранение картинок

Есть доска объявлений. Высоконагруженная. К каждом объявлений могут добавляться по несколько фото. До этого я всегда использовал отдельную таблицу, в которую записывал путь в фоткам и связывал с таблицей объектов. Как мне кажется у этого способа есть недостаток. При добавлении, лишние запросы. Потом при выводе, опять обращение к таблице с фотками. И еще таблица получится большой(количество объявлений умножается на среднее количество фоток на каждое объявление).

Подумал о другом способе. При загрузке 4 фотографий, для определенного объекта ID=3 записать файлы по такому шаблону
3_1.jpg
3_2.jpg
3_3.jpg
3_4.jpg
При загрузке, запись в базе не будет. При выводе, опять не будет обращение к базе. А файлы искать в папке по шаблону. Но вот я не уверен что это будет быстрее чем поиск по таблице. Кто с таким сталкивался?

Я всегда использую второй способ.

Бенчмарков не делал, но по сути, в первом случае получаем:
Запрос к БД - запрос к БД - вывод картинки.

А во втором:
Запрос к БД - Вывод картинки...

Логично, что должно работать быстрее.

WebDesignStudio, а второе число откуда берётся что в цикле file_exists или поле с количеством картинок к объявлению(не не вариант с удалением)? Можно в отдельное поле сериализованный массив записывать а название картинок дататаймстемп+разрешение джипег. А по шаблону это ж искать то как а если в папке 100 тыщ файлов всё ж повиснет?

Anexroid, я тоже подумал что быстрее.
mishustin_s, Да, в цикле. удалять не так сложно как кажется.
neadekvat, вот я тут не очень уверен. Ведь на базу и так нагрузка будет большая.

А если чтоб не юзать file_exists() в поле БД хранить кол-во загруженных картинок? И в цикле до "кол-ва" выводить по шаблону ID_i.jpg

Цитата ("Anexroid"):

А если чтоб не юзать file_exists() в поле БД хранить кол-во загруженных картинок? И в цикле до "кол-ва" выводить по шаблону ID_i.jpg

Ну можно и это.

Я в парсерах использовал конструкцию if(file_exists) при больших кол-вах её вызова отнимается большой кусок времени, не знаю как на серверных винтах, но на домашнем ПК это было значительно. Я бы советовал хранить в таблице с объявлениями сериализованный массив картинок. таким образом Вы будете использовать всего один запрос для выбора объявления и картинок.

----

Нашел даже более точные данные:

             => Array

                (

                     => 6.02651929855

                     => 58172

                )

Время замерялось в теле функции. функция содержала только проверку if (file_exists()) die();

exec_cnt = кол-во запросов
work_time = время работы в секундах

hdd обычный домашний sata винт.

Цитата ("Anexroid"):

А если чтоб не юзать file_exists() в поле БД хранить кол-во загруженных картинок? И в цикле до "кол-ва" выводить по шаблону ID_i.jpg

В таком случае будут проблемы, если мы захотим удалить 3и из 10 картинок. придется либо их все переименовывать и изменять счетчик, либо опять же использовать file_exists

Цитата ("WebDesignStudio"):

Anexroid, я тоже подумал что быстрее.
mishustin_s, Да, в цикле. удалять не так сложно как кажется.
neadekvat, вот я тут не очень уверен. Ведь на базу и так нагрузка будет большая.

Я не писал что удалять сложно просто это не логично и не удобно в случае удаления, хранение сериализованного массива в поле ограничения накладываются на количество картинок, запись сериализованного массива в файл - не практично много лишнего места на диске занимается но это не критично, можно просто при создании нового объявления в папке images создавать папку чьё название ID объявления, тогда чтобы вывести картинки к объявлению нужно будет просто просканировать папку а при удалениии объявления удалить её и содержимое - по мне самый практичный вариант.

Цитата ("mishustin_s"):

можно просто при создании нового объявления в папке images создавать папку чьё название ID объявления, тогда чтобы вывести картинки к объявлению нужно будет просто просканировать папку а при удалениии объявления удалить её и содержимое - по мне самый практичный вариант.

Объявлений будет не меньше 10 тысяч. Столько папок???

Цитата ("neadekvat"):

Так как поиска по фотографиям не будет

Зато может быть удаление и добавление. Не очень удобно.

А что такого?

neadekvat, одна показывается в списке. до этого я проблему решал просто. Одну фотку(главную) держу в таблице объектов а остальные в отдельной таблице. 1 запрос. На сколько я вижу лучшего способа нет.

Цитата ("WebDesignStudio"):

объявлений будет не меньше 10 тысяч.

10 000* 10 = 100 000 строк с именами файлов с индексом по id объявления.. в 99% случает sql будет держать в кэше ответы на запросы и всю таблицу.

По ссылке с хабра случайно наткнулся: ссылка

Возможно будет интересно, там есть и про хранение фотографий.

4VIY, Как раз полчаса назад это читал.
Ну я не фейсбук делаю. У меня попроще.

Думаю можно делать основную выборку через file_exists и кешировать результаты в таблицу с товаром (если это потребуется). Туда складывать в одно поле все картинки. Делаем что-то с картинками - поле это очищаем, при следующем запросе оно будет восстановлено как надо. И превьюхи можно подобным образом генерить. Тогда можно без проблем менять их размеры, например.

Цитата ("frig"):

Думаю можно делать основную выборку через file_exists и кешировать результаты в таблицу с товаром. Туда складывать в одно поле все картинки. Делаем что-то с картинками - поле это очищаем, при следующем запросе оно будет восстановлено как надо. И превьюхи можно подобным образом генерить. Тогда можно без проблем менять их размеры, например.

А в чем плохо, хранить сразу результаты в сериализованном (json/xml) формате.

advert_id
advert_category_id
advert_name
advert_text
advert_photo
advert_preview

1. На выборку объявы 1 запрос SELECT, и его делать в любом случае
2. При изменении тоже 1 запрос UPDATE, и при хранении каких-то данных про картинки, его тоже надо делать

Зачем изобретать колесо? Или я не правильно понял задачу

Цитата ("SField"):

А в чем плохо, хранить сразу результаты в сериализованном (json/xml) формате.

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

Хранить таблицу с картинками имеет смысл, пожалуй, только если к ним надо подписи привязывать. Так ведь?