Привет всем. Помнится мне, что в Oracle была возможность запихать рисунок в базу данных с удаленного хоста и извлекать его из нее по мере необходимости.
После поисков по инету нашел следующий рецепт (как я понял, данный метод используется только для хранения изображений):
CREATE TABLE image ( name text, raster oid ); INSERT INTO image (name, raster) VALUES ('beautiful image', lo_import('/etc/motd')); SELECT lo_export(image.raster, '/tmp/motd') FROM image WHERE name = 'beautiful image';
Так же, прочитал, что этот метод не работает с удаленного хоста...
Подскажите, как можно записывать и извлекать изображения из базы данных с удаленного хоста (желательно помещать туда еще и doc файлы).
ЗЫ. Разработку веду при помощи qt-sql (4.5.X)
Одна из ошибок разработчиков
Одна из ошибок разработчиков (это моё личное, хотя и очень глубокое убеждение) - это использовать БД для таких вещей, для которых её не надо использовать. К ним как раз относится хранение картинок и документов в бинарных форматов в БД. Действительно, для чего мы сохраняем информацию в БД? Для того, чтобы среди однотипной информации её можно было извлечь, задав определённые условия, т.е. грубо говоря обеспечить поиск нужной записи по каким-то уникальным признакам или агрегировать, обсчитать массив информации и т.д. Для файлов в бинарном формате ничего этого нет, СУБД превращается в простое хранилище куска неиндексируемой информации, выдаваемой по ключу. При этом хранилище весьма неэффективное - объём БД раздувается, методы извлечения и размещения имеют низкое быстродействие и жрут много ресусов, в случае краха БД восстановлению не подлежит!
Выводы: не нужно использовать БД для хранения файлов, для этого есть ФАЙЛОВЫЕ протоколы: smb. ftp, http. Все они позволяют авторизацию. А вот что можно хранить в БД - это ПУТИ к этим файлам и описания файлов, возможно даже какую-то информацию, связанную с доступом (пароли и т.д.)
Но это была лирика. Хранить бинарные объекты в БД PostgreSQL разумеется можно.
Читайте:
http://postgresql.ru.net/manual/datatype-binary.html
http://postgresql.ru.net/manual/largeobjects.html
удалённое всё должно работать:
http://postgresql.ru.net/manual/lo-funcs.html
Ещё один способ, если не хочется связываться с большими объектами: взять бинарный файл, пропустить его через кодировщик MIME или UUE и получившийся текст сохранить в поле с типом TEXT. Соответственно обратное получение - это декодировние. Такой способ ещё и будет более переносимым между разными СУБД.
Спасибо за ответ
По поводу лирики. Если Вы не знаете, что необходимо сделать, так зачем критиковать? Если есть возможность хранения бинарной информации в базе данных, значит это действительно нужно.
В моем проекте именно необходимо хранить БИНАРНУЮ информацию в базе данных.
ЗЫ. Спасибо за ответ.
> Если Вы не знаете, что
> Если Вы не знаете, что необходимо сделать, так зачем критиковать?
В том-то и дело, что сколько раз я сталкивался с проектами, которые хранили файлы в БД столько раз это самое хранение давало такие минусы, которые перевешивали все плюсы. Впрочем как я писал вначале предыдущего поста - это МОЁ ЛИЧНОЕ мнение. Вы же можете оставаться при своём - это ваше право.
Попробую mime поковырять
Попробую mime поковырять
допустим, есть
допустим, есть кросс-платформенное клиент-серверное приложение (разработка, как Вы знаете, не ограничивается вебом).
Поднимать ftp? smb? http? Может быть, sendmail использовать? А если БД необходимо перенести с одного сервера на другой? На другую платформу?
Если у вас есть сервер, то
Если у вас есть сервер, то поднять на нём ещё одну службу со стандартным протоколом типа http или ftp - это совершенно не проблема. Платформа здесь вообще не при чём, потому что протоколы СТАНДАРТНЫЕ ДЛЯ ЛЮБОЙ ПЛАТФОРМЫ. Как говориться: ftp он и в Африке ftp.
Видел я серверы документооборота, где PDF, XLS и DOC хранились непосредственно в БД в BLOB'ах. При этом СУБД далеко не последняя: Informix. При этом БД была под 100G всего-то (где кстати метаданные документов и вся кухня документооборота занимали меньше 2G - остальное были сами документы), но даже на таком мощном сервере как SunFire 880, с 8G оперативки, 4мя процессорами и SCSI-fiberchannel винтами, ворочалось очень тяжело! И клиентов-то активных было всего человек 30-40.