- Поисковые системы
- Практика оптимизации
- Трафик для сайтов
- Монетизация сайтов
- Сайтостроение
- Социальный Маркетинг
- Общение профессионалов
- Биржа и продажа
- Финансовые объявления
- Работа на постоянной основе
- Сайты - покупка, продажа
- Соцсети: страницы, группы, приложения
- Сайты без доменов
- Трафик, тизерная и баннерная реклама
- Продажа, оценка, регистрация доменов
- Ссылки - обмен, покупка, продажа
- Программы и скрипты
- Размещение статей
- Инфопродукты
- Прочие цифровые товары
- Работа и услуги для вебмастера
- Оптимизация, продвижение и аудит
- Ведение рекламных кампаний
- Услуги в области SMM
- Программирование
- Администрирование серверов и сайтов
- Прокси, ВПН, анонимайзеры, IP
- Платное обучение, вебинары
- Регистрация в каталогах
- Копирайтинг, переводы
- Дизайн
- Usability: консультации и аудит
- Изготовление сайтов
- Наполнение сайтов
- Прочие услуги
- Не про работу
Авторизуйтесь или зарегистрируйтесь, чтобы оставить комментарий
в целом, как я вижу минусы пересиливают. легче хранить картинки в папках и не париться
Давным давно уже это выяснено. :)
Лет 7-10 назад на школохостах такое было, чтобы безопасностью не заморачиваться
хранить картинки в БД - эт маразм, мощности и технологии не позволяют
нормально с картинками работать (например рога кому-нить в перспективе подрисовать) - куча манипуляционного геммороя... ))
edogs, в определенных условиях все может стать и плюсом и минусом.
вот, например :
я вот заметил, что sypex dumper спотыкается на таблицах, где "лежат" картинки
ну не смогли даже написать такой продукт, который бы не спотыкался. Какая уж там синхронизация между серверами
Про "Супербезопасность" не понятно, что мешает нормально настроить права доступа при хранении не в БД?
Что-то обязательно помешает.
Стратегия построения безопасного ПО подразумевает избыточные перекрывающие друг друга механизмы.
edogs, в определенных условиях все может стать и плюсом и минусом.
вот, например :
ну не смогли даже написать такой продукт, который бы не спотыкался. Какая уж там синхронизация между серверами
Пример-то в другую сторону 😂 О том что базу не всегда можно сдампить даже иногда. А вот с ФС никакой проблемы с синхронизацией не было бы, качнул файл и ура.
edogs, не пойму о чем речь. я не утверждаю, что хранение картинок нужно прямо сейчас вам. И ТС не спрашивал нужно ли это ему. Он спросил чем вообще такое решение может быть оправдано. И эти причины могут существовать несмотря на традиционные програмисткие штампы.
Давным давно уже это выяснено. :)
Лет 7-10 назад на школохостах такое было, чтобы безопасностью не заморачиваться
причём тут старые школохосты? некоторые современные CMS поддерживают это
я знаю одну такую СМС, имя ей SharePoint, у нее вообще все файлы в базе лежат.
MS утверждает что как раз в базе (MS SQL) и нужно хранить файлы.
так что от БД зависит, не все БД одинаково заточены под работу с двоичными данными, тот же MS SQL 6.5 с ними плохо работал, сейчас допилили.
iopiop, пользователю совсем не обязательно верить всему тому, что ms утверждает о своих продуктах. Думать тоже нужно.
iopiop, пользователю совсем не обязательно верить всему тому, что ms утверждает о своих продуктах. Думать тоже нужно.
думать полезно всегда конечно.
навскидку могу назвать две причины почему файлы в базе лучше чем в ФС:
1) количество системных вызовов типа fopen в ФС зависит от глубины вложенности каталогов, если, скажем, глубина 5, то для открытия файла придется сделать fopen 6 раз. База же, вообще делает fopen один раз при старте.
2) если файлов много - база находит нужный файл фактически мгновенно за счет использования индексов, ФС, в большинстве своем, индексы не строит, значит поиск нужного файла существенно медленнее.
1) количество системных вызовов типа fopen в ФС зависит от глубины вложенности каталогов, если, скажем, глубина 5, то для открытия файла придется сделать fopen 6 раз.
😮 Это откуда такая информация?
Файл открывается fopen()-ом за один вызов.
А представьте, какое количество fseek()-ов делает база для поиска нужных данных в файле-таблице с использованием бинарного индекса.
База же, вообще делает fopen один раз при старте.
База делает fopen() как минимум каждый раз, когда возникает временная таблица.
Неиспользуемые таблицы база закарывает. Это я наблюдаю в настоящий момент, сравнивая количество файлов таблиц с количеством открытых файлов таблиц.
Это я всё об MySQL.
2) если файлов много - база находит нужный файл фактически мгновенно за счет использования индексов, ФС, в большинстве своем, индексы не строит, значит поиск нужного файла существенно медленнее.