Как сохранить в базе картинку?

[SanitaR]

Собственно сабж.

[RXL]

SanitaR, сабж то к яве отношение не имеет - выбирай для вопросов соответствующую ветку! Посему перенес в "Базы данных".

А теперь собственно сабж...
О, сколько раз твердили миру... :? Не надо хранить картинки и прочие крупные бинарные файлы в базах. Базы это могут, но от этого только падает скорость поиска/вставки. Картинки следует хранить на диске в виде файлов, а в базе хранить пути к ним.
Конечно, может быть специальный случай, что к этим картинкам доступ возможен только через эту БД. Для таких случаев существуют соотв. типы полей в БД. Какие именно - посмотри в доке к своей СУБД. Кстати, ты не назвал какая у тебя СУБД.

[Alf]

Вопрос, конечно, лаконичен до предела... Под "базой", надо полагать, подразумевается база данных? И какая именно?..
Вообще-то для хранения подобных объектов заведомо большого и заранее неизвестного размера в большинстве достаточно развитых баз данных существуют специальные типы данных, обобщенно называемые BLOB (Binary Large Objects). Хотя этот тип и не входит в стандарты SQL/89 и SQL/92, но по этому ключевому слову в документации наверняка найдется реализация данного типа в конкретной СУБД. Так, например, в Transact SQL (диалект SQL для Microsoft SQL Server) этот тип называется image и может содержать любые двоичные данные размером до 2Гбайт в каждой записи. В базах Microsoft Jet (aka Access) аналогичный тип носит название "Поле объекта OLE". Коллеги, работающие с Oracle, Interbase и MySQL, могут дополнить, как BLOB реализован на их любимых платформах.
А теперь по поводу:

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

Не вносите дополнительную неразбериху в этот и без того далекий от совершенства мир... Пусть существующие СУБД и далеки от идеала, но по крайней мере у их разработчиков хватило сообразительности не хранить BLOB'ы физически там же, где и "строки" таблиц. Так, например, в MS SQL поле image фактически является ссылкой на размещение данных и занимает всего 16 байт. Не столь уж великие накладные расходы, чтобы существенно повлиять на скорость поиска, особенно если индексы построены с умом. Конечно, если кто-то вздумает сделать поиск по самому двоичному содержимому картинки, хранящейся в BLOB'е... Но это уже патология, и таких "программистов" лучше все-таки изолировать от сервера.

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

Недавно я опубликовал перевод статьи Дейкстры "Смиренный программист". Не могу не привести цитату из нее: "...мы должны быть очень осторожны, давая советы молодежи: иногда они следуют им!"
Предположим, я поверил приведенным выше доводам, сделал директорию, перенес в нее несколько тысяч файлов с картинками и принялся заполнять базу "путями к ним". По ходу возникает несколько вопросов.
1. Каким образом планируется поддерживать целостность столь шаткой структуры? Как убедиться в том, что в базе отсутствуют "слепые" ссылки, которые указывают на несуществующие файлы, и "бесхозные" файлы, на которые нет ссылок? Как гарантировать синхронное добавление/удаление файла и записи со ссылкой на него? Сочинять специальный инструментарий? Нанимать специального человека?
2. Разумеется, клиента интересует не имя файла, в котором сидит картинка, а само содержимое картинки. Следовательно, на сервере, помимо самого SQL-сервера, будет открыт еще и файловый сервис со всеми вытекающими прелестями: разделяемый ресурс, открытые порты NetBIOS для доступа к файлам по SMB, столь лакомые для "червяков" вроде LoveSun, головная боль с прописыванием прав доступа... Думаю, администраторы, ответственные за сетевую безопасность, будут чрезвычайно благодарны за такое решение, ибо это их надежная гарантия от безработицы. А если сервер еще и в открытой сети стоит...
Есть и еще вопросы, но полагаю, что и этих вполне достаточно, чтобы всерьез призадуматься.

[Fireworm]

Во многом согласен с Alf, но выбор хранить или не хранить картинки в базе - зависит от СУБД и конкретной задачи.
Если вы делаете веб-приложение на БД MySQL - ответ - картиники не стоит хранить в БД. Лучше в файлах.

Как это реализовани в Оракле: Есть несколько типов данных для хранения такой информации:
1. BLOB - до 4 Гб. Данные хранятся в базе, но в отдельном файле(в одном файле может хранится несколько блобов). В структуре таблице хранится только указатель на эти данные.
2. BFILE - до 4ГБ. Этот вариант соответствует предложенному RXL. Т.е. сами данные хранятся вне базы. В специальной папке. т.е. можно свободно просматривать и редактировать эти файлы через файловую систему (но лучше этого не делать, а делать через базу). В Базе хранится относительный путь к файлу и имя файла.


Так что выбор реализации зависит от БД и от конкретной задачи.

[Kuzmich]

Fireworm, Хотя я и не эксперт в БД, но аргументы Alf'а звучат убедительней. В конце концов реляционные базы данных делали для того чтобы упростить жизнь, зачем же тогда ее себе усложнять ? Если в БД при этом падает производительность, то это проблемма БД, но никак не твоя.

[x77]

господа, позвольте, я пробью с ноги

Alf, безусловно, прав, в том, что хранить картинки в базе, как сылки на сами файлы - это чушь. при практически любых раскладах. для стандартной ситуации (т.е. некий более/менее сервак в некоей более/менее сети, хранящий некие, достаточно большие, например, фото человека, данные) имеет смысл делать локальное кэширование, т.е. в таблице заводится дата последнего обновления, и копии картинок хранятся локально. приложение при запросе на отображение картинки, берёт с сервака только одну дату (реально, дату - и некий id). если дата совпадает с локальной, выводится картинка с диска. если не совпадает, картинка полностью вытаскивается с сервака с обновлением, есс-но, текущей даты.

короче, смысл не в том, чтобы хранить ссылки, а в том, чтобы организовать грамотную репликацию "по запросу". и тогда будет счастье. возьмите тот же MIDAS. никто ведь не заставляет циклиться на 3х-звенке, технология позволяет организовать вполне приличную flat-file базу данных. со всеми вытекающими прелестями - индексированным поиском и пр.

по большому счёту, так организовывается любое локальное кэширование. есть таблица с кучей полей в каждой записи, которая долго тащится по сети. у неё есть уникальный id и дата изменения. при необходимости вывести её на экран, запрашиваем c сервера дату последнего обновления, совпало - выводим с диска, не совпало - перегружае с сервака. для большинства приложений, работающих с анкетнымми или просто большими, но достаточно редко меняемыми данными, типа БОСС-Кадровик,  Guards, etc. - это оптимальный вариант. другой вопрос, почему они этого не делают.

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

[Slavka]

Вопрос не в лоб, а по лбу(с)

Уже есть [не]правильная БД SQL Server где картинки ХРАНЯТСЯ в поле типа image. Вопрос как используя только SQL (_не_ ASP, VB ), те как написать store procedure кот. сохраняет image в файле.

Минута пошла(с) 8)

[Dimka]

Хранимую процедуру (универсальную) не напишешь по той простой причине, что переменные SQL Server могут хранить данные не более чем 8 Кб. Можно напрямую через ADO выполнять INSERT или UPDATE. Другой способ... почитай в BOL всё, что связано с BULK. Третье решение мне неизвестно...

[x77]

Slavka, присоединяюсь к dimka, никак это средствами SQL не сделать. програмно - без проблем. эсть, в принципе, ещё одна нетривиальноая возможность, насчёт MSSQL врать не буду но в IB это есть - т.н. external files. т.е. можно внешний (читай - обычный, d.o.s.-овский) файл назначить таблицей и сливать туда всё, что угодно.

[Ostrik]

Вот только мне тогда интересно!!!Если у меня FireBird, Delphi7(BDE), как сохранять картинки в БД? Хранить путь или картинку, а с учетом >20000 Записей в базе?

[Алексей++]

Ostrik, храни в BLOB https://forum.shelek.ru/index.php/topic,6103.0.html

а ещё лучше - хранить картинки на диске, а хранить в базе пути к картинкам

[Джон]

Ostrik, на самом деле вопрос так не стоит. Это две разные концепции, каждая их которых имеет право быть.
Всё зависит от требований предъявляемых к этой БД.

[x77]

Ostrik, всё, что писалось выше, относится к технологиям и техническим возможностям, имевшим место 6 лет назад. на сегодняшний день любая нормальная СУБД (и FB в т.ч.) позволяет хранить хоть миллион картинок. но надо учитывать ряд вещей.

1. никогда не тащить картинки в большом запросе - дёргать сам запрос, а картинки подгружать по мере навигации по полученной выборке. если на MSSQL сделать запрос из 20.000 записей с картинками - он тупо умрёт на полчаса. в FB блоб-поля подгружаются "on-demand", по требованию, и там ситуация несколько лучше.
2. никогда не хранить картинки в RAW-форматах, таких, как bmp. либо хранить как векторное изображение, либо как компрессионное (тот же jpeg). там, где это уместно - применять архивирование/разархиварование на лету.
3. грамотно проектировать БД, с учётом её архитектурных особенностей. и в MSSQL, и в FB можно указывать размер блоба, который физически ляжет в таблицу (остальное будет хранится в отдельных участках БД). в зависимости от среднего размера картинок, требований к скорости выборки и объёмам БД, всем этим можно и нужно играть.

и наконец, всегда надо отталкиваться от требований к задаче. есть картинки, которые весят дясятки гигабайт (спутниковая сьёмка, например). сам процесс заливки их в БД, как бы, несколько проблематичен, их и на экран-то так просто не выведешь - только через специальные софтины, маппинг в память и т.д. поэтому начинать надо всегда с конкретики: шо трэба?