Главная страница
Top.Mail.Ru    Яндекс.Метрика
Текущий архив: 2016.01.31;
Скачать: CL | DM;

Вниз

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

 
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]

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


 
pavel_guzhanov ©   (2015-05-28 16:43) [29]

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


 
Дмитрий Белькевич ©   (2015-05-28 16:57) [30]

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


 
RWolf ©   (2015-05-28 16:58) [31]

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


 
Дмитрий Белькевич ©   (2015-05-28 16:58) [32]

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

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


 
кгшзх ©   (2015-05-28 17:58) [33]

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

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


 
ухты ©   (2015-05-28 17:59) [34]

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


 
Jeer ©   (2015-05-28 18:35) [35]

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

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

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

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


 
Eraser ©   (2015-05-28 20:08) [36]


> Ega23 ©   (28.05.15 10:31) 

наверное зависит от задачи. для веб решений фактически однозначно надо хранить в файлах.


 
ogs ©   (2015-05-28 23:41) [37]

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


 
Jeer ©   (2015-05-29 08:32) [38]

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


 
virex(home) ©   (2015-05-29 09:35) [39]


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

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

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


 
DVM ©   (2015-05-29 10:30) [40]

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



Страницы: 1 2 вся ветка

Текущий архив: 2016.01.31;
Скачать: CL | DM;

Наверх




Память: 0.57 MB
Время: 0.007 c
2-1404898048
alexdn
2014-07-09 13:27
2016.01.31
Изменить записи в MainMenu


15-1432504637
Германн
2015-05-25 00:57
2016.01.31
Зависает IDE при запуске проекта по F9


15-1432714180
Pavia
2015-05-27 11:09
2016.01.31
Двойной замок


2-1404816598
Sakipiel
2014-07-08 14:49
2016.01.31
Можно ли положить форму на форму?


2-1404910328
Imagination
2014-07-09 16:52
2016.01.31
В Stringgrid точку поменять на запятую