Я тут смотрю, начали ср.. споры возникать всякие

← →
Ega23 © (2015-05-28 10:31) [0]

Подкину-ка на пропеллер: храните ли картинки в БД или рядом в файлах держите?

← →
кгшзх © (2015-05-28 10:33) [1]

Удалено модератором

← →
Ega23 © (2015-05-28 10:35) [2]

Удалено модератором

← →
Юрий Зотов © (2015-05-28 10:43) [3]

В разных случаях по-разному. От задачи зависит.

← →
Ega23 © (2015-05-28 10:50) [4]

> В разных случаях по-разному. От задачи зависит.

Вот мне сосед вчера втирал, что их вне базы хранить офигенно удобно.
Но лично я пока, кроме ограничения на размер самой БД, никаких доводов не вижу.

← →
DVM © (2015-05-28 10:54) [5]

От хранения в БД одни плюсы, минусов нет никаких кроме суеверий.

← →
Юрий Зотов © (2015-05-28 10:56) [6]

> Ega23 © (28.05.15 10:50) [4]

Если юзер имеет право редактировать картинку.
Если у каждого юзера своя картинка.
Если картинка используется и другими программами.

и т.п.

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

← →
DVM © (2015-05-28 10:58) [7]

А вот от хранения в файлах одни сплошные минусы:

1) Сложности с разграничением доступа.
2) Сложности с удаленным доступом к файлам (надо передавать пути открывать порты или городить какие то протоколы)
3) Сложно поддерживать целостность базы и ссылок на файлы.
4) Сложности с одновременным доступом.

← →
Ega23 © (2015-05-28 11:00) [8]

> Если юзер имеет право редактировать картинку.

Во-во, вчера мне тоже такой довод был приведён. А буквально через 15 минут поступила жалоба на тупых пользователей, которые при редакции аватары размерами 100х100 зафигачили туда 40-метровую фотку в FullHD

← →
junglecat © (2015-05-28 11:08) [9]

> при редакции аватары размерами 100х100 зафигачили туда 40-
> метровую фотку в FullHD

дык это... валидацию надо прикручивать

← →
Ega23 © (2015-05-28 11:10) [10]

> дык это... валидацию надо прикручивать

Куда? Файл-то вне БД лежит, делай с ним что хош.

← →
Юрий Зотов © (2015-05-28 11:11) [11]

> Ega23 © (28.05.15 11:00) [8]

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

← →
Юрий Зотов © (2015-05-28 11:15) [12]

> Ega23 © (28.05.15 11:00) [8]

Кстати, ничто не мешает юзеру зафигачить 40-метровую фотку и в BLOB, не только в файл.

← →
DVM © (2015-05-28 11:16) [13]

> Юрий Зотов © (28.05.15 11:15) [12]

> Кстати, ничто не мешает юзеру зафигачить 40-метровую фотку
> и в BLOB, не только в файл.

Ну в блоб он через проводник не зафигачит. А в программе и проверку можно сделать.

← →
Ega23 © (2015-05-28 11:24) [14]

> Кстати, ничто не мешает юзеру зафигачить 40-метровую фотку
> и в BLOB, не только в файл.

Это уже на твоей совести будет, что проверку не поставил. Просто так блоб заменить нельзя.

← →
Dimka Maslov © (2015-05-28 11:26) [15]

А я вообще БД не использую.

← →
Юрий Зотов © (2015-05-28 11:31) [16]

> DVM © (28.05.15 11:16) [13]

Если юзер должен иметь право редактировать картинку, то изначально она по-любому будет в файле. И ничто не помешает юзеру зафигачить туда 40-метровую фотку.

Оставить эту 40-метровую картинку в файле или сразу загрузить ее в BLOB (самой же этой программой) - это уже второй вопрос. В любом варианте юзер должен получить ошибку, только на разных этапах (либо позже, при попытке программы отобразить картинку, либо сразу, при ее загрузке в BLOB).

← →
кгшзх © (2015-05-28 11:32) [17]

Куда? Файл-то вне БД лежит, делай с ним что хош.

они что там у вас автары для чятичов прямо на диски фигичат минуя веб-морды?

← →
Ega23 © (2015-05-28 11:34) [18]

> они что там у вас автары для чятичов прямо на диски фигичат
> минуя веб-морды?

не-не-не-не, меня сюда не приплетайте.

← →
Юрий Зотов © (2015-05-28 11:40) [19]

> Ega23 © (28.05.15 11:24) [14]

> Это уже на твоей совести будет, что проверку не поставил.

Верно, при загрузке файла в BLOB должна быть проверка. Но никто не мешает сделать такую же проверку и при загрузке файла не в BLOB, а для показа картинки.

Ты пойми главное: "если юзер должен иметь право редактировать картинку, то изначально она по-любому будет в файле. И ничто не помешает юзеру зафигачить туда 40-метровую фотку" (сорри за самоцитату).

Поэтому при загрузке этого файла с любой целью (хоть в BLO, хоть для показа) должна быть проверка. С выдачей оговоренной в документации ошибки.

← →
DVM © (2015-05-28 11:48) [20]

> Юрий Зотов © (28.05.15 11:31) [16]

BLOB тут вообще ни при чем. Что программа в блоб положит то и будет.
Путь юзер оперирует хоть стогигабайтной фоткой, но при попытке ее сохранения в базу:
1) должно быть предупреждение, что фотка слишком большая.
2) предложение преобразовать размер к необходимому.

← →
Юрий Зотов © (2015-05-28 11:53) [21]

> DVM © (28.05.15 11:48) [20]
>
> Путь юзер оперирует хоть стогигабайтной фоткой, но при попытке
> ее сохранения в базу:
> 1) должно быть предупреждение, что фотка слишком большая.
> 2) предложение преобразовать размер к необходимому.

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

← →
кгшзх © (2015-05-28 11:55) [22]

1) должно быть предупреждение, что фотка слишком большая.

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

← →
Игорь Шевченко © (2015-05-28 11:57) [23]

Ega23 © (28.05.15 10:31)

> храните ли картинки в БД

Храним. Только не картинки. Точнее, не только картинки. Иногда удобно, иногда неудобно, поэтому у нас вариативность, хочешь хранить в базе, храни, не хочешь, не храни.
Всяких ужасов не наблюдали.

← →
brother © (2015-05-28 14:27) [24]

когда работал в одной газетной конторе, то движок сайта (его писали не самые глупые люди и сами же поддерживали) с нагрузкой более 100000 уникальных хранил картини отдельно, файлами...

← →
Illusion © (2015-05-28 14:37) [25]

> От хранения в БД одни плюсы, минусов нет никаких кроме суеверий.

ну конечно. Ты рассматриваешь ситуацию, когда приложение десктоп и с картинками работает только твоя программа.

Стоит перейти в WEB и тут вообще все в другую сторону:

1) картинки может отдавать сервер, а не программа, программа только ссылки на картинки генерирует в выходном HTML. Более того, для отдачи статики есть куча специализированных решений.

2) невозможна групповая обработка фотографий внешними программами.

Натравить утилиту на каталог с картинками - это обычно. Натравить утилиту на каталог картинок в БД - гораздо все менее прозрачно.

← →
manaka © (2015-05-28 14:40) [26]

> Подкину-ка на пропеллер: храните ли картинки в БД или рядом
> в файлах держите?

Можно еще в TImage хранить на соседней форме (невидимой)
))))))))))))))

← →
кгшзх © (2015-05-28 14:46) [27]

самый тру способ - это внутри css хекс-строкой

← →
Дмитрий С © (2015-05-28 16:21) [28]

Хранил на одном фото-сайте, перестал из-за того что нагрузка на базу большая в момент открытия альбома и работает медленно.

Когда начал заниматься веб-программированием, на многих форумах и в статьях прочитал, что хранить фотки в базе - дурной тон. Почему - не знаю:о)

Рядом. Во-первых - потому, что храним терабайты (пока) скоро - десятки тб по количеству видел свои базы с 100 млн файлов, нормально работали. Во-вторых, даже когда мало мне кажется удобнее хранить файлами. Есть свои плюсы, не смотря на описанные в [7] сложности, разруливаем их все как-то.

Чересчур большой фотке можно поменять размеры при сохранении. Юзер доволен, база спасена.

Рядом. Во-первых - потому, что храним терабайты (пока) скоро - десятки тб, по количеству видел свои базы с 100 млн файлов, нормально работали. Во-вторых, даже когда файлов мало, мне кажется, удобнее хранить файлами. Есть свои плюсы, не смотря на описанные в [7] сложности, разруливаем их все как-то.

p.s. не хватает некоторых фишек в форуме...

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

а если это типо фотогаллери на вебе, то и файлы пофик

да, в облаках надо держать :)

Один из хороших примеров - offline просмотрщик гео-данных SAS-planet.
Изначально, в локальный кэш транслировались файлы-тайлы изображений (карты, спутник), поскольку именно так принято в гео-сервисах Google, Bing, Digital Clobe и других. Тайлы - файлы в jpg или png 256x256.

По ходу разработки активно обсуждалась идея размещения всего этого в БД, был даже сделан клон, где было реализовано такое размещение.

Доводы, в общем-то разумные, поскольку при реальной работе число файлов быстро зашкаливает за миллионы и начинается деградация FS.

В итоге от БД отказались из-за явного замедления работы, а проблема деградации решена использованием файлового контейнера, например TrueCrypt.

Удалено модератором

> DVM © (28.05.15 10:58) [7]
> А вот от хранения в файлах одни сплошные минусы:
>
> 1) Сложности с разграничением доступа.
> 2) Сложности с удаленным доступом к файлам (надо передавать
> пути открывать порты или городить какие то протоколы)
> 3) Сложно поддерживать целостность базы и ссылок на файлы.
> 4) Сложности с одновременным доступом.

это да
5) файл может называться одинаково но разное содержимое, поэтому при добавлении нового файла придется сканить на уникальность имени и сохранять например так: file_1.txt
6) при удалении, если есть несколько ссылок на один "физический" файл - то удалять файл можно только когда в базе больше нет других ссылок
7) перед сохранением/удалением файла в сетевую папку, нужно к ней залогиниться от учетки с правом записи в папку (чтобы юзвери не могли в ней натворить делов), в итоге например отследить стандартными средствами windows владельца файлов бесполезно
... и другие увлекательные особенности

переделывал сохранение файлов на сетевую папку, потом был долгий невеселый процесс отладки

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

Я тут смотрю, начали ср.. споры возникать всякие Найти похожие ветки