Целесообразно ли хранить картинки в БД?

Question

[elailasou]

Использую MySQL, PHP.
Делаю систему постинга, картинки каждого поста нужно куда-то сохранять.
Целесообразно ли хранить картинки в БД? Или лучше реализовать хранение в папках файлами?

Comments

[Алексей Немиро]

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

Если нужно ограничить доступ к картинкам, то можно делать выдачу силами PHP, на основе данных в базе (проверка существования записи в базе, проверка прав, поиск файла в файловой системе и его выдача). Это будет лучше, чем если бы данные полностью хранились в базе. А лучше, сделать перенаправление к физическому файлу. Например, идет обращение к файлу: images.example.org 123, где 123 - это идентификатор записи о файле в базе данных. Если запись с идентификатором найдена и пользователю разрешен доступ к файлу, можно создать временный физический файл и выдать на него ссылку пользователю. Затем просто перенаправить пользователя к этому физическому файлу. Срок жизни ссылки и файла ограничить. Нагрузка на сервере будет минимальной. Это принцип в общих чертах, и только если требуется организовать разграничение доступа к файлам.

Answer 1

[Максим Кудрявцев]

Картинки в БД хранить плохо и вот почему.

Если картинка лежит в БД, то для того чтобы ее вытащить нужен php-скрипт, который отправит запрос на ее извлечение. Будет формироваться диначеское содержимое, работает Apache.

Если картинка лежит в папке, то для ее отображения достаточно просто обратится к ней по УРЛу. Здесь можно обойтись без скрипта, следовательно может работать только nginx.

В чем суть - nginx кушает НАМНОГО меньше ресурсов, по сравнению с apache. Статистику можете погуглить.

Единственное ограничение при использовании хранилища в папках - для *nix папка не может содержать более 42 с чем-то тысяч файлов(с цифрой могу ошибаться, но не суть), поэтому учтите этот аспект.

Comments

[neol]

Единственное ограничение при использовании хранилища в папках - для *nix папка не может содержать более 42 с чем-то тысяч файлов(с цифрой могу ошибаться, но не суть), поэтому учтите этот аспект.

Не знаю откуда вы взяли эту информацию, но она ложна. В принципе можно миллионы файлов в одну директорию скинуть. Правда посмотреть содержимое этой директории будет проблематично (но возможно), так что лучше все-таки делать некую структуру директорий для хранения.

[Евгений]

про файлы – бред, хранить много можно (я видел по 100к файлов в папке), но лучше так не делать
про ресурсы, апаче и nginx тоже бред, ведь можно сделать кеш, достать 1 раз из базы картинку скриптом и закешировать в nginx

[Максим Кудрявцев]

Покопался в сети и признаю, да - написал бред. Когда я набирал это почему-то думал о NTFS, где есть ограничения на длинную пути и количество вложенных файлов
https://ru.wikipedia.org/wiki/NTFS
https://ru.wikipedia.org/wiki/%D0%A1%D1%80%D0%B0%D...

Answer 2

[Евгений]

Нецелесообразно

Answer 3

[raiboon]

В MySQL хранить картинки ужасно, да и использовать MySQL, когда есть Postgres.
А вообще в бд, то в теории можно, в том же риаке или монге - без проблем.

Comments

[elailasou]

Что такое риак и монг?

[Евгений]

junk1114: гавнецо ноуэсклюэльное, очевидно же )

Answer 4

[Anton Kuzmichev]

Оба методы имеют свои достоинства и недостатки, но всё же хранение в виде простых файлов более органично. Это статика, которую нужно отдавать пользователю без участия скриптов.

Answer 5

[Шаров Дмитрий]

саму картинку в папке, доп инфу в бд

Answer 6

[zed]

Целесообразно ли хранить картинки в БД?

Зависит от количества картинок. Картинки можно хранить и в файловой системе или даже в той же БД, где и данные, но это, имхо, крайний случай, если картинок не очень много. НО если вы пишите свой инстаграм, то для картинок однозначно нужна своя БД. Заметьте - БД именно для картинок, а не для данных + картинок. Т.е. эти вещи нужно разносить по разным базам. И если данные лучше хранить в SQL, то картинки можно сложить и в NoSQL.

Это на самом деле очень сложный вопрос - как оптимально хранить бинарные данные.