Найти - Пользователи
Полная версия: Хранение изображений в БД
Начало » Базы данных » Хранение изображений в БД
1
dissdoc
Всем привет! Это не холивар))) После глубокого изучения MySQL, SQLServer и MongoDB (причем здесь и NoSQL? узнаете позже) пришел к раздумьям и не знаю что делать… Есть изображения - их много. Раньше как делал - в БД хранил ссылку, а картинки на диске.
Теперь, когда появились поля типа BLOB, стал сомневаться - может туда пихать их?
Собственно хочу хранить данные пользователей в БД отдельной, а куда девать изображения не знаю. Имеет смысл в БД аватары хранить или нет?
С условием того, что юзеров переношу в MongoDB, так проще мне в дальнейшем работать.
masterito
Смысла в этом я не вижу. БД для структурированной информации, которой картинка не является.
С этой задачей лучше справится файловая система.
o7412369815963
в MongoDB есть GridFS, только я не знаю есть ли там отдача по http.
а вообще в файловой системе - нормально, тем более их ассортимент.
dissdoc
Хм..
может я просто уже перемудрил… Файловая система действительно быстрее и проще… =\
Ох моя голова)))) Рукам покоя не дает)
villager
а если клиент-серверная система на БД MySql, и у клиента нет доступа к сетевым дискам?
как в таком случае поступать?
doza_and
А может и не перемудрили. Если у вас большая локалка, или интернет, то база данных в отличии от fs обеспечит передачу файлов клиентам и их кеширование на стороне клиента. Кроме того как и обычно, будет обеспечена транзакционная целостность при изменении контента, и будут более разнообразные возможности при разрешении конфликтов доступа. Если перечисленное не нужно тогда - файловая система лучше. правда но… Если картинок много и они мальенькие (100-200-500 байт как у иконок) тогда накладные расходы fs могут быть значительны. (Например вам нужна база данных отпечатков пальцев всего населения). В этом случае БД тоже может выиграть. (не проверял)
kachayev
doza_and
В этом случае БД тоже может выиграть. (не проверял)
Может, но только в том случае, если она поддерживает асинхронный I/O. В противном случае упретесь в тоже самое. Отсюда mysql и подобные сразу отпадают.
o7412369815963
doza_and
А может и не перемудрили. Если у вас большая локалка, или интернет, то база данных в отличии от fs обеспечит передачу файлов клиентам и их кеширование на стороне клиента. Кроме того как и обычно, будет обеспечена транзакционная целостность при изменении контента, и будут более разнообразные возможности при разрешении конфликтов доступа. Если перечисленное не нужно тогда - файловая система лучше. правда но… Если картинок много и они мальенькие (100-200-500 байт как у иконок) тогда накладные расходы fs могут быть значительны. (Например вам нужна база данных отпечатков пальцев всего населения). В этом случае БД тоже может выиграть. (не проверял)
1) файловую систему легко сделать распределенной
2) маленькие/большие файлы - выберите себе подходящий тип ФС - их десятки
3) “кеширование на стороне клиента” - это не зависит как хранить файлы на сервере
4) “ обеспечена транзакционная целостность” - это зависит о движка и в том и в том случае.

так что все плюсы перекрыты.

тут надо смотреть конкретную базу, как она по скорости, расширяемости, возможность отдачи по http…
alexandre
Еще есть аналог MongoDB, CouchDB там вообще все просто к каждому документу приатачиваються любые файлы в любом количестве, а при желании эти файлы могут участвовать в запросах. Очень удобно впринцепе.
Sleepwalker
Более того сама CouchDb работает по http протоколу, следовательно картинки можно грузить непосредственно с Couch. Правда не знаю на сколько это хорошо с точки зрения производительности (стоит почитать) но возможность такая есть.
This is a "lo-fi" version of our main content. To view the full version with more information, formatting and images, please click here.
Powered by DjangoBB