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


Автор: polosatij 18.9.2007, 15:40


собственно сабж.. стоит ли  smile 

п.с. что-то меня какие-то мутные сомнения по этому поводу терзают.. не лучше ли напрямую в файловую систему?  smile 

Автор: Akina 18.9.2007, 15:58
Как правило нет, лучше в БД хранить URI картинок.

Автор: Anark1 18.9.2007, 16:06
В зависимости от сервера и размеров \ количества картинок.
Если пишется сервер для вэб сайта, который требует подгрузки пары десятков gif`ов, то вполне целесообразно хранить их в BLOB полях.
Как никак схема Сервер - БД будет работать быстрее чем Сервер - БД - Файл, тем более при больших выборках. Стоит призадуматься разве что в случае если размеры изображений очень большие. Насколько я знаю файлы, хранящиеся в БД, занимают несколько больше места.

Автор: polosatij 18.9.2007, 17:07
Цитата(Anark1 @  18.9.2007,  16:06 Найти цитируемый пост)
В зависимости от сервера и размеров \ количества картинок.
Если пишется сервер для вэб сайта, который требует подгрузки пары десятков gif`ов, то вполне целесообразно хранить их в BLOB полях.
Как никак схема Сервер - БД будет работать быстрее чем Сервер - БД - Файл, тем более при больших выборках. Стоит призадуматься разве что в случае если размеры изображений очень большие. Насколько я знаю файлы, хранящиеся в БД, занимают несколько больше места. 



речь идёт про очень большой в будущем интернетпортал..
есть определённые разделы и пользователю нужно дать возможность сохранить картинку(и)..

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

Автор: Akina 18.9.2007, 17:22
Цитата(Anark1 @  18.9.2007,  17:06 Найти цитируемый пост)
Если пишется сервер для вэб сайта, который требует подгрузки пары десятков gif`ов, то вполне целесообразно хранить их в BLOB полях.

А на клиента эти гифы что, не в файловой форме отдаваться будут? Это разве что в случае, когда клиентская часть - НЕ браузер...

Цитата(polosatij @  18.9.2007,  18:07 Найти цитируемый пост)
речь идёт про очень большой в будущем интернетпортал..
есть определённые разделы и пользователю нужно дать возможность сохранить картинку(и)..

Тогда имхо все-таки файловое хранилище. 

Автор: Anark1 18.9.2007, 18:06
Сейчас работаю с IB, имею многотабличную структуру с большим количеством изображений, которые хранятся в BLOB. Никаких сбоев, падений, тормозов и т.д. не наблюдал. И это IB, а если использовать, например Oracle...
В общем сколько людей, столько мнений. Во всяком случае мое мнение подкреплено опытом.  smile 

Автор: polosatij 18.9.2007, 19:04
Anark1, 

a как поведёт себя MySQL ты не в курсе?  smile 

Автор: LSD 18.9.2007, 21:24
Если картинки хранятся в ФС, то веб-сервер может их сам оттуда забрать. Что уменьшает нагрузку на СУБД. Но требует дополнительной синхронизации, если несколько потоков будут отдновременно менять одну и ту же картинку.

Автор: Akina 18.9.2007, 21:32
Цитата(Anark1 @  18.9.2007,  19:06 Найти цитируемый пост)
Во всяком случае мое мнение подкреплено опытом.  

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

Цитата(LSD @  18.9.2007,  22:24 Найти цитируемый пост)
Если картинки хранятся в ФС, то веб-сервер может их сам оттуда забрать. Что уменьшает нагрузку на СУБД. 

А на серьезном портале они вообще будут закэшены фронт-эндом и даже из ФС не будут браться. Даже запрос на них до движка веб-сервера не будет доходить.

Автор: Anark1 18.9.2007, 21:37
Akina, не понимаю, что хочешь из меня вытащить? Уличить в чем то? Или в том, что я не прав? Что такое клиент ты можешь узнать в яндэксе или гугле. И где я говорю общие фразы? 

Powered by Invision Power Board (http://www.invisionboard.com)
© Invision Power Services (http://www.invisionpower.com)