Сохранение jpg в БД

Преимущество:

- нет проблем с путями / правами

Недостатки:

- медленней работает

- база нагружается лишней работой

- жирнее бэкап, если понадобится восстанавливать/перезаливать

Растет на размер jpeg-ов.

В подавляющем большинстве случаев у этого способа - сплошные недостатки.

Редкие случаи преимуществ - это когда БД и ФС оказываются на разных физических носителях и по какой-то причине ФС уже загибается от нагрузки, а БД еще бодрячком. В частности иногда это бывает если БД на отдельном сервере, но в таком случае еще сетевые задержки надо учитывать.

Совсем редкий случай это когда ЦМС стоит на сервере, где админ на голову больной немного, и файлы создавать не разрешает скриптами 😂

Как пример: vbulletin по умолчанию все аттачи и фотки хранит в базе. Не раз писали скрипты для перекладывания в ФС - нагрузка на сервер снижалась реально в разы, в 10-20 раз - легко.

Скрипты? Дак она сама умеет перекладывать туда-сюда :)

в целом, как я вижу минусы пересиливают. легче хранить картинки в папках и не париться

Не так все просто:)

Вобла ранних версий перекладывать не умела.

Кроме того вобла не умеет класть аттачи в прямой доступ (может последние научились, но кажется еще нет), то есть для отдачи аттача вобла мало того что в базу за инфой по нему лезет (то же имя файла хранится только в базе, в ФС его нет) - что приводит к лишнему коннекту и нескольким запросам, так еще и сам файл отдаваемый через php скрипт пропускает (а не напрямую) - а файлы большие через пхп гонять тоже мало радости.

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

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

Согласны, вобла в меру всего этого не очень пример, но с другой стороны кто его знает как там у ТС цмс с файлами теми же работает:)

---------- Добавлено 17.08.2012 в 01:01 ----------

плюсы:

- Проще сделать бекап сразу всех данных сайта. Один файл - один слепок состояния сайта. А файлы движка всегда можно взять из дистрибутива.

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

- Супербезопасность: все скрипты и папки сайта "замораживаются" с помощью установки таких прав доступа, что файлы вообще нельзя модифицировать ни с помощью украденного пароля от ftp, ни логической уязвимостью в коде. Закачать файл веб-шелла просто некуда. И при этом сайт будет нормально работать. Конечно, украсть данные все еще будет можно, но при попытке сделать классический дефейс хакер будет весьма озадачен.

---------- Добавлено 17.08.2012 в 01:28 ----------

Не то чтобы лишним. Она проверяет права доступа. Если доступ в раздел закрыт, предполагается, что никакую информацию из этого раздела получить нельзя в том числе и картинки.

весьма интересно, спасибо

Так подумаешь на сколько БД станет больше и ну его нафиг )) Тем более тогда отдача статики через тот же nginx - уже просто невозможна, придется за каждой фоткой в БД лезть через Apache, или скрипт для nginx писать, кошмар.

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

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

netwind,

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

Про "Супербезопасность" не понятно, что мешает нормально настроить права доступа при хранении не в БД? Тем более что творится в папках для загрузки можно контролировать... И опять же это только фотки, стоит добавить видео или еще чего и начинаются проблемы опять как всегда и все сходит на нет. Да бекап делать удобнее, слил БД, но бекап может быть таким что литься он будет очень значительное время, думаю и там будут свои подводные камни при большом размере БД.

Не плюс. Если уж запустил бакап БД и потом его скачиваешь, то не велик труд скачать еще и папку с файлами. И даже скорее минус. Т.к. сдампить 20гб базу с файлами несколько труднее, чем синхронизировать 20гб папку с файлами. Вы вообще когда-нибудь пробовали сдампить базу 20гб? И Вам реально нравится идея ее потом одним куском качать лишаясь синхронизации возможной на файлах?

Не плюс. Файлы абсолютно спокойно раскладываются по разным папкам, которые по сети монтируются откуда угодно. Даже скорее минус. Т.к. файлы можно хранить на отдельных файл-сторажах типа амазоновского и все такое.

Не плюс. Файлы кладутся в папку откуда запрещается что-либо запускать и всего делов. Не говоря уже о том, что nginx можно настроить на эту папку, что бы он тупо отдавал оттуда статику. Но не минус, окей:)

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

я вот заметил, что sypex dumper спотыкается на таблицах, где "лежат" картинки