Стоит ли хранить изображения в бд?

Question

[DmitrijP]

Доброго времени суток!

Делаю заказ, заказчик хотел бы, что бы в базу данных (около 11 тысяч уникальных записей) можно было для каждой добавлять картинку. Естественно никто её вручную сжимать не будет. Вопрос: можно ли хранить и выводить практически одновременно такой объём данных? Или стоит объяснить заказчику что это нельзя использовать (заказчик готов обсуждать эту тему, и в случае невозможности согласен отказаться от изображений)?

Заранее спасибо.

Comments

[Ninazu]

Вопрос какая задача стоит? Почему статика не устраивает?

[Владислав Лысков]

Нет, картинки в бд хранить ни при каких условиях не стоит

[Дмитрий]

Храните в файлах, в базе только ссылка

Answer 1

[Владимир Коротенко]

Мое мнение хранить в базе стоит только метаданные, а картинки в файловой системе.

Плюсы и минусы

В ФС
+ Прямой доступ от вебсервера
+ Меньший обьем БД
+ Меньше тормоза на выборку, коннект доступен сразу
+ Меньший обьем памяти под кэши
- невозможно контролировать отдачу клиенту картинки не добавив код
- нужно бэкапить не только базу

В базе
+ нет мусора в файловой системе
+ можно отдавать картинку определенному клиенту и с определенной скоростью
+/- все в кэше, но прогибаем память, но быстро, но нгинкс все же быстрей
- размер дампа
- тормоза репликации
- просмотреть картинку целый атракцион

Comments

[DmitrijP]

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

[Дмитрий]

Лучше и не опишешь

[Владимир Коротенко]

DmitrijP, Я в одном из проектов сделал так

База

id -long autoincrement
name - varchar[255] original name
.....

структура хранилища

/storage/1/
/storage/1/1/
/storage/1/2/
.....
/storage/2/
.....

Контроллер перевертывает id изображения и копирует в папку файл, для более ровного наполнения

например 189.jpg

Ляжет в
/storage/9/8/189.jpg

И настройка NGINX

https://img.host.org/189.jpg

[DmitrijP]

Владимир Коротенко, Хороший метод,однако также хотел бы спросить про одну из главных сторон вопроса:это всё равно займёт огромное количество места для хранения на диске хотстинга и работа сайта будет медленнее чем без картинок?

[Владимир Коротенко]

DmitrijP, Ну и пусть занимает. Не заморачивайтесь. Или в какой то момент человек решит вставить антихотлинкинг и ваши картинки превратятся в "тыкву".

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

[DmitrijP]

Владимир Коротенко, Pardon Me! Where Do I Find 4giveness? , Изучив ответы склоняюсь всё же к тому что данная система только всё испортит,спасибо за ваше участие

[Владимир Коротенко]

Pardon Me! Where Do I Find 4giveness? гипотетический вариант 2х типов картинок 1 для Премиумов по подписке, а все остальное для всех.

Это либо усложнять скрипт, пусть даже ставим простой 301-302 и пропускаем все картинки через него, не используя NGINX как то мне этот вариант не очень нравится.

[DmitrijP]

Владимир Коротенко ,Премиума не будет,проект для конкретных целей и прям в общем использовании не будет,макс 100 человек .

Answer 2

[Alex]

Тут мне нравится подход в WordPress:

1. В базе данных хранятся имена файлов (aaa.png, bbb.jpg);
   
2. Отдельно в БД или ещё где-то хранится путь к каталогу, где эти файлы искать. (/path/to/img/folder/);
   
3. В файловой системе в указанном выше каталоге, хранятся все файлы с указанными выше именами;
   
4. Отдельно в том же месте хранятся оптимизированные, уменьшенные, как либо измененные файлы, с тем же именем но специальным суффиксом. (aaa-100-100.png, aaa-800-600.png, aaa-4k.png).
   
5. А далее всё просто: при необходимости получить конечный урл на файл мы указываем ИД файла в БД и суфикс.
   
   

   <?php
   getImageURL(1, '800-600'); // → /path/to/img/folder/aaa-800-600.png
   ?>

   
   
   И уже эта функция подставляет нужный суффикс и префикс к пути.
   
   

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

Comments

[DmitrijP]

сайт на php и html,к сожалению wordpress не вариант

[Alex]

DmitrijP, Я не предлагаю использовать wordpress. Я только указал на применяемый подход к хранению файлов. Вы можете реализовать точно такой же на php

[DmitrijP]

прошу прощения,невнимательно прочитал ваш ответ.)

Answer 3

[FanatPHP]

Какой-то странный вопрос.
То есть в бд место под картинки есть, а просто на диске нету? Это где такая конфигурация бывает?

По-моему вы с заказчиком путаетесь в понятиях и не понимаете каких-то базовых принципов.

Такое ощущение, что вы считаете базу данных каким-то волшебным хранилищем, которое сжимает картинки в сто раз.

И при чем здесь "сжимать вручную"? Чем не устраивает сжимать скриптом?

PS: Как всегда, остальные ответы в стиле "папа ты с кем сейчас разговаривал"

Comments

[DmitrijP]

FanatPHP, бд и фс имеют общие размеры,это я понимаю,вопрос то в том,правильно ли хранить столько объёма информации?

[FanatPHP]

Вопросы все смешнее и смешнее.
Ну ты же сам собирался хранить "такой объем" информации. А теперь спрашиваешь, правильно ли хранить.

И где здесь "такой объем"? Твои объемы - это воробей чихнул.
У пятиклассника на телефоне порнухи на порядки больше накачано, чем эти несчастные 10 тыщ картинок.

Короче.
Картинки сжимай скриптом. На тостере примерно сто тысяч миллионов ответов, как это делать.
После сжатия клади на диск.
Хранение картинок для записей - совершенно тривиальная задача, ту вообще не о чем думать

Answer 4

[Лев Забудкин]

Давайте предположим, на секунду, что картинки в базе.
Это же надо при запросе такой картинки, её вынуть и передать.
Если картинка на диске, то просто отослать по запросу и всё.
Разницу в скорости где-то 100 кратная.
Не нужно в базе хранить картинки.