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

123
pauk
На сайте с 26.01.2005
Offline
543
#11
SiteProd:
в целом, как я вижу минусы пересиливают. легче хранить картинки в папках и не париться

Давным давно уже это выяснено. :)

Лет 7-10 назад на школохостах такое было, чтобы безопасностью не заморачиваться

Hi!
[Удален]
#12

хранить картинки в БД - эт маразм, мощности и технологии не позволяют

нормально с картинками работать (например рога кому-нить в перспективе подрисовать) - куча манипуляционного геммороя... ))

N
На сайте с 06.05.2007
Offline
419
#13

edogs, в определенных условиях все может стать и плюсом и минусом.

вот, например :

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

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

Segey:
Про "Супербезопасность" не понятно, что мешает нормально настроить права доступа при хранении не в БД?

Что-то обязательно помешает.

Стратегия построения безопасного ПО подразумевает избыточные перекрывающие друг друга механизмы.

Кнопка вызова админа ()
edogs software
На сайте с 15.12.2005
Offline
775
#14
netwind:
edogs, в определенных условиях все может стать и плюсом и минусом.
вот, например :

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

Пример-то в другую сторону 😂 О том что базу не всегда можно сдампить даже иногда. А вот с ФС никакой проблемы с синхронизацией не было бы, качнул файл и ура.

Разработка крупных и средних проектов. Можно с криптой. Разумные цены. Хорошее качество. Адекватный подход. Продаем lenovo legion в спб, дешевле магазинов, новые, запечатанные. Есть разные. skype: edogssoft
N
На сайте с 06.05.2007
Offline
419
#15

edogs, не пойму о чем речь. я не утверждаю, что хранение картинок нужно прямо сейчас вам. И ТС не спрашивал нужно ли это ему. Он спросил чем вообще такое решение может быть оправдано. И эти причины могут существовать несмотря на традиционные програмисткие штампы.

SiteProd
На сайте с 17.10.2010
Offline
22
#16
pauk:
Давным давно уже это выяснено. :)

Лет 7-10 назад на школохостах такое было, чтобы безопасностью не заморачиваться

причём тут старые школохосты? некоторые современные CMS поддерживают это

I
На сайте с 23.12.2010
Offline
25
#17

я знаю одну такую СМС, имя ей SharePoint, у нее вообще все файлы в базе лежат.

MS утверждает что как раз в базе (MS SQL) и нужно хранить файлы.

так что от БД зависит, не все БД одинаково заточены под работу с двоичными данными, тот же MS SQL 6.5 с ними плохо работал, сейчас допилили.

N
На сайте с 06.05.2007
Offline
419
#18

iopiop, пользователю совсем не обязательно верить всему тому, что ms утверждает о своих продуктах. Думать тоже нужно.

I
На сайте с 23.12.2010
Offline
25
#19
netwind:
iopiop, пользователю совсем не обязательно верить всему тому, что ms утверждает о своих продуктах. Думать тоже нужно.

думать полезно всегда конечно.

навскидку могу назвать две причины почему файлы в базе лучше чем в ФС:

1) количество системных вызовов типа fopen в ФС зависит от глубины вложенности каталогов, если, скажем, глубина 5, то для открытия файла придется сделать fopen 6 раз. База же, вообще делает fopen один раз при старте.

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

[umka]
На сайте с 25.05.2008
Offline
456
#20
iopiop:

1) количество системных вызовов типа fopen в ФС зависит от глубины вложенности каталогов, если, скажем, глубина 5, то для открытия файла придется сделать fopen 6 раз.

😮 Это откуда такая информация?

Файл открывается fopen()-ом за один вызов.

А представьте, какое количество fseek()-ов делает база для поиска нужных данных в файле-таблице с использованием бинарного индекса.

iopiop:
База же, вообще делает fopen один раз при старте.

База делает fopen() как минимум каждый раз, когда возникает временная таблица.

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

Это я всё об MySQL.

iopiop:
2) если файлов много - база находит нужный файл фактически мгновенно за счет использования индексов, ФС, в большинстве своем, индексы не строит, значит поиск нужного файла существенно медленнее.
Лог в помощь!
123

Авторизуйтесь или зарегистрируйтесь, чтобы оставить комментарий