Хранение изображения и *.doc файлов в базе данных

Привет всем. Помнится мне, что в 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.

Опции просмотра комментариев

Выберите предпочитаемый вами способ показа комментариев и нажмите "Сохранить настройки" для активации изменений.

Back to top

(С) Виктор Вислобоков, 2008-2023