Хабр Курсы для всех
РЕКЛАМА
Практикум, Хекслет, SkyPro, авторские курсы — собрали всех и попросили скидки. Осталось выбрать!
Хабр доступен 24/7 благодаря поддержке друзей
Комментарии 25
для этого придумали FileStream
Сколько живу, столько зову извращенцами кадров, хранящих в базе изображения и прочие не текстовые данные.
Или я не понял ход Ваших мыслей или…
> Скорость. Пожалуй, одно из самых важных преимуществ. Дело в том, что при хранении в БД нам надо произвести следующие действия для вывода изображения: считать стрим из базы, создать временный файл, записать в него стрим. Из файловой же системы его достаточно только считать.
Зачем нам записывать данные в файл, если их надо отдать клиенту (речь ведь про веб-сервер)? Надо их считать и выдать в поток (сокет), через которых их получит клиент.
> Универсальность. Обычные изображения можно использовать для множества приложений: переслать через фтп, добавить в письмо, показать в браузере. Бинарные данные из базы необходимо сначала конвертировать.
Мы все еще говорим про веб-сервер? Он всем этим не занимается. Он только может отдавать изображения клиентам, в исходном виде или после какой-либо обработки «на лету»
> Простота реализации. Закачать файл на сервер и сохранить ссылку на него в таблицу легче, чем реализовывать логику сохранения бинарных данных в ту же таблицу. А простота — это скорость разработки и внесения изменений. Время — деньги.
В случае с файлом нужно совершить два действия (записать файл и поместить ссылку на него в таблицу), в случае с хранением в БД — только одно.
> И если база вдруг накроется (представим, что бэкапов не было), то хотя бы изображения не потеряются.
Вы совершенно верно заметили, что и то и другое бэкапить нужно, от этого никуда не деться.
Реально у хранения изображений в файловой системе (т.е. статически!) есть одно важное преимущество — web-сервер (программа, например nginx или apache) хорошо (быстро и эффективно) умеют работать со статическими ресурсами, выдавать их клиентам, указывать, необходимо ли обновить этот ресурс или достаточно прочитать из кэша клиента и т.п. В случае с БД этот функционал придется писать самому (или пользоваться готовыми решениями), если он нужен.
Поэтому:
— если Вы однажды помещаете изображение на сервер и дальше будете его только выдавать клиентам в неизменном виде, то лучше хранить его в файле.
— если же изображение будет обрабатываться перед выдачей, меняться в зависимости от запросов клиента и вообще вести бурную жизнь, то лучше его хранить в БД.
> Скорость. Пожалуй, одно из самых важных преимуществ. Дело в том, что при хранении в БД нам надо произвести следующие действия для вывода изображения: считать стрим из базы, создать временный файл, записать в него стрим. Из файловой же системы его достаточно только считать.
Зачем нам записывать данные в файл, если их надо отдать клиенту (речь ведь про веб-сервер)? Надо их считать и выдать в поток (сокет), через которых их получит клиент.
> Универсальность. Обычные изображения можно использовать для множества приложений: переслать через фтп, добавить в письмо, показать в браузере. Бинарные данные из базы необходимо сначала конвертировать.
Мы все еще говорим про веб-сервер? Он всем этим не занимается. Он только может отдавать изображения клиентам, в исходном виде или после какой-либо обработки «на лету»
> Простота реализации. Закачать файл на сервер и сохранить ссылку на него в таблицу легче, чем реализовывать логику сохранения бинарных данных в ту же таблицу. А простота — это скорость разработки и внесения изменений. Время — деньги.
В случае с файлом нужно совершить два действия (записать файл и поместить ссылку на него в таблицу), в случае с хранением в БД — только одно.
> И если база вдруг накроется (представим, что бэкапов не было), то хотя бы изображения не потеряются.
Вы совершенно верно заметили, что и то и другое бэкапить нужно, от этого никуда не деться.
Реально у хранения изображений в файловой системе (т.е. статически!) есть одно важное преимущество — web-сервер (программа, например nginx или apache) хорошо (быстро и эффективно) умеют работать со статическими ресурсами, выдавать их клиентам, указывать, необходимо ли обновить этот ресурс или достаточно прочитать из кэша клиента и т.п. В случае с БД этот функционал придется писать самому (или пользоваться готовыми решениями), если он нужен.
Поэтому:
— если Вы однажды помещаете изображение на сервер и дальше будете его только выдавать клиентам в неизменном виде, то лучше хранить его в файле.
— если же изображение будет обрабатываться перед выдачей, меняться в зависимости от запросов клиента и вообще вести бурную жизнь, то лучше его хранить в БД.
Я примерно то же самое и хотел сказать, что у вас в последнем параграфе.
Только насчет «бурной жизни» не совсем понятно. Вы хотите операции напрямую над бинарными данными проводить? Если нет, то разницы где хранить изображение нет.
Только насчет «бурной жизни» не совсем понятно. Вы хотите операции напрямую над бинарными данными проводить? Если нет, то разницы где хранить изображение нет.
> В случае с файлом нужно совершить два действия (записать файл и поместить ссылку на него в таблицу), в > случае с хранением в БД — только одно.
На самом деле в случае с БД тоже два. Содержимое файла как правило обычно получают из временного файла. В остальном полностью с Вами солидарен.
На самом деле в случае с БД тоже два. Содержимое файла как правило обычно получают из временного файла. В остальном полностью с Вами солидарен.
большой плюс хранения файлов в базе, когда их тысячи и размер не более 1 метра,
в остальных случаях файловая система
в остальных случаях файловая система
Что-то ни_о_чем статья у Вас получилась. Вывод какой-то странный…
Например, что мешает шифровать файлы, и выдавать через скрипт дешифрованный стрим?
Основные проблемы хранения изображений в файлах это:
— при большом кол-ве файлов, файловая система начинает тормозить (СУБД, как правило хранят все с физически одном файле);
— целостность базы при удалении (надо заботиться об удалении файла, а не только записи в БД).
Но первое решается созданим структуры каталогов, и раскидыванием в них файлов,
и второе, не такой уж «гемморой», для большинства задач лечится периодической «сборкой мусора» из крона.
Например, что мешает шифровать файлы, и выдавать через скрипт дешифрованный стрим?
Основные проблемы хранения изображений в файлах это:
— при большом кол-ве файлов, файловая система начинает тормозить (СУБД, как правило хранят все с физически одном файле);
— целостность базы при удалении (надо заботиться об удалении файла, а не только записи в БД).
Но первое решается созданим структуры каталогов, и раскидыванием в них файлов,
и второе, не такой уж «гемморой», для большинства задач лечится периодической «сборкой мусора» из крона.
Как вариант хранение база + кеш в файловую систему
Для маленького проекта — плохое решение
Зато для большого — когда куча серверов и нужно масштабирование — очень даже ничего )
Для маленького проекта — плохое решение
Зато для большого — когда куча серверов и нужно масштабирование — очень даже ничего )
у хранения в базе главный плюс — это контроль за целостностью данных
Обсуждалось миллион раз. В том числе и на Хабре.
habrahabr.ru/blogs/mysql/45966/
habrahabr.ru/blogs/mysql/45966/
Зато из базы труднее проксировать в nginx
а зачем их шифровать?
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Где хранить изображения