Вопрос:

Есть БД на Oracle.
Требуется организовать хранение файлов ЛЮБЫХ! типов в БД с возможностью поиска текста по текстовым документам (вероятно Oracle Text, blob).
Каким образом лучшк организовать доступ и просмотр файлов из клиента (клиент толстый, С++, OCI). Начальство хочет видеть реализацию OLE в клиенте, то есть может прямо в окошке клиента в OLE-контейнере посмотреть файлик, подредактировать и т.д., кто-нибудь так делал? По-моему очень нестабильно и реализация будет слишком сложной,если не сказать что в потребном виде это сделать просто невозможно (почитал-потестил по теме, кажется именно невозможным сделать универсальный вариант с обработкой ЛЮБЫХ файлов). К тому же OLE подразумевает хранение данных в Compound Storage, который реализовать в Oracle можно, но текстового поиска по форматированным документам точно не будет из-за специфики сохранения OLE объектов.

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

Какие будут мысли по-поводу? Есть что присоветовать?

Да, и еще. Подразумевается что открывать в клиенте файлы для просмотра нужно через OCI напрямую с БД, не копируя файл или какие-либо данные непосредственно на ПК клиента. Потому что могут быть достаточно большие видео-файлы.

Programmer_OrtodoxВариант с OLE нормально работает, минимум кодинга и максимум универсальности. Отсутствие гемора с админством, если всё хранится в БД. Полнотекстовый поиск я пока не сделал, но он достаточно прост (в рамках подхода,который я собираюсь применить). Так что, проверено, мин нет!

Можно вопрос: а что у вас за документы используются через OLE? Безусловно хороший вариант, когда используются, скажем, только OLE-объекты Microsoft Office.

Programmer_OrtodoxЛюбые файлы можно хранить как object package, exe, zip,...и самые экзотические.
Да, тут ты без сомнения прав, но только у меня начальство этот вариант не удовлетворил, потому что Windows Packager при активации OLE-объекта распаковывает его в исходный файл в TEMP и оттуда его выполняет. :) При открытии больших видео-файлов будет тормоз...
К слову сказать, Windows Packager немного глюкавая утилитка по одной причине - не принимает исходные данные в виде файла, а требует указатель на HGLOBAL, поэтому при создании БОЛЬШИХ OLE-объектов может просто кончиться память, у меня при тестировании (создать из 1.5 Гб видео-файла) вывалилась ошибка - в системе кончилась память, а у меня 1 Гб ОЗУ + 1.5 Гб свап. >-] Это конечно был эдакий черезчур стресс-тест, но клиент должен работать на гораздо более слабых машинах чем у меня. К тому же при пользовании Windows Packager будут проблемы с In-Place Activation.

Programmer_OrtodoxА что касается Windows Packager и HGLOBAL, то я с ними и не парился. У меня просто открывается файл(любой) через стандартный диалог, он падает в динамически создаваемый OLE-объект. Всё.

Я с ними парился, чтобы понять, что и как неправильно работает, когда выявился глюк с видео-файлами. Я попытался сам создать экземпляр Com-объекта Windows Packager, и ему скормить этот файл - так он забрыкался, и я проверил, то, какие параметры он принимает, небольшим скриптиком.
А диалог есть стандартный виндовый. :)

P.S. Если делать самостоятельные типы и т.д. То лучше уж совсем не заморачиваться с OLE, а сделать типовое решение с перекачкой именно файлов.

Programmer_OrtodoxСогласен, но здесь разница в трудозатратах будет основательной.
Вы вроде Delphi-разработчик, если это делать на Дельфи, то, пожалуй, да. А вот на С++...

Programmer_OrtodoxНа счет OLE я пожалуй не готов согласиться. Довольно удобная вещь, когда например, делаешь документ Word, а туда требуется включить фрагмент (а не весь файл, который очень большой) из Autocad, Excel и P-CAD. Сохраняется как OLE-Word, потом может многократно редактироваться, причем всё это должно быть оперативно, без лишних телодвижений.

Но у меня то не форматированный документ, а Клиент-серверная система и основная цель - централизованное хранение файлов в Базе данных и обеспечение доступа к ним, а остальное - это уже второстепенные вещи. Без OLE будет достигнуто более универсальное и, главное, НАДЕЖНОЕ решение, ИМХО.

guest_20040621> Надежное универсальное решение - хранить файлы в файловой системе. Любые другие варианты за незначительным исключением - от лукавого.

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

guest_20040621> В данном случае нет

Дружище, кривая архитектура приложения не оправдывает кривых решений.


Мну и какая же может быть прямая архитектура приложения, когда, например, админ конторы, которая купила продукт, позволяет устанавливать игрушки на сервере? Тут хоть распрямая архитектура приложения будет - все равно ж*па. :)
А контора сервера клиентов не админит.

guest_20040621> когда, например, админ конторы, которая купила продукт, позволяет
> устанавливать игрушки на сервере?

Дебилы есть не только среди системных администраторов, - не новость. Непонятно, как это связано с Вашим вопросом?

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