Разработка хранилища данных

1. http://plone.org/
2. дело ваше

С ума сойти...

Пункт 2 - это целая индустрия. Над вопросами грамотного поиска не одна сотня умов бьётся.

Пункт 3 - это даже две задачи необъёмного размера. У самого мс не всегда получается отображать документы в своих же форматах. Да и откуда вы возьмёте описания закрытых форматов? Ну даже, предположим, каким-то лыком найдёте, что дальше? Писать парсер и рендер? Это очень много человеко-лет.

Сервис Google Docs арендовать не дешевле будет? Реальней то уж точно...

Для хранения сырых данных - ФС
если нужна дополнительная мета информация - SQL
для отображения FUSE
для поиска beagle
для редактирования - штатные средства

1. use fs, DB плохо для оного -в DB ты можешь удачно хранить инфу о хранящийся документации.

2. задача не тривиальна - тк ты имеешь закрытый формат - и к каждому парсер - дальше рассказывать ?

3. как и в пункте 2 - ууу как все не будет просто

это не в development пост - ибо никакой конкретики просто нет.

> наверное oracle

http://www.oracle.com/technology/products/text/index.html

Помнится, утверждали, что в 11 версии оно уже работает с русским языком нормально.

:-)

> 1. хранилище данных/базу данных (наверное oracle) для хранения документов в различных форматах (doc,dbf,xls,txt,...).

> 2. Грамотный поиск по всем имеющимся документам.

посмотри в сторону Apache Lucene. Для индексации микрософтовских форматов она использует Apache POI. Есть порты Lucene на С++ и С

Автоматизируя бардак, вы получаете авоматизированный бардак;)

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

Под перечисленные форматы есть парсеры для жабы. Поэтому как платформу лучше взять Java Enterprise Edition 5.

в oracle и так есть средства data mining, вот и используй их

>для поиска beagle

лучше tracker

> 1. Какие существуют качественных разработки, желательно open source

см. в сторону "семантического десктопа", API вроде Tenor ^W Nepomuk в KDE, tracker в GNOME

> 1. хранилище данных/базу данных

почитай про хранилища данных, OLAP на том же citkit.ru, erpnews.ru. В любом случае придётся чтобы это хранилище наполнить ложить не просто документы блобами, а с метаданными для поиска, индексирования, теги/категории/автор/оглавление, и т.п. Придётся писать какой-то парсер чтобы автоматически эти метаданные из исходных файлов генерировал.

Ещё см. поисковый движок Sphinx на С++ http://www.sphinxsearch.com/ для поиска по содержимому, русский с морфологией. Там вроде плагины были для обработки разных форматов, по крайней мере XML интерфейс точно был.

http://www.wikinfo.org/index.php/Comparison_of_desktop_search_software http://en.wikipedia.org/wiki/List_of_search_engines#Desktop_search_engines http://en.wikipedia.org/wiki/List_of_search_engines#Open_source_search_engines http://en.wikipedia.org/wiki/Search_oriented_architecture http://en.wikipedia.org/wiki/Category:Free_search_engine_software

> Система в дальнейшем будет усложняться до кис

что эта КИС должна делать?

> 2. Какой выбрать инструментарий для разработки

зависит от. Прототип можно сделать вообще "палками и верёвками": десктопный поиск вроде tracker или Strigi, управление ими по d-bus скриптами.
Если эта "типа КИС" должна работать с транзакциями, возникает сервер приложений, параллельные транзакции и процессы.
Чтобы эту "типа КИС" можно было расширять прозрачно независимо, ортогонально, нужна правильная архитектура вроде SOA. Отдельно хранилище данных, отдельные слабозацепленные модули-сервисы, отдельный общий framework для запуска сервисов в транзакциях, в сервере приложений. "Хранилище данных" выступает с одной стороны, хранилищем метаданных (реестр сервисов SOA, адаптеров к данным, описания бизнес-процессов/транзакций/словарей данных), с другой стороны, хранилищем данных в БД некотором унифицированном формате. То есть, данные в хранилище хранятся в одном "универсальном" формате, адаптеры читают разные форматы и подготавливают метаданные для описания. Поиск работает по данным в унифицированном формате+метаданным.

Ссылки: много текста про SOA (на том же ibm.developersworks.ru, erpnews.ru) как архитектуру, про "Унифицированную модель данных": http://www.citforum.ru/database/articles/udm/ http://citforum.univ.kiev.ua/seminars/cbd2002/111.shtml , cм. также ссылки. http://www.altlinux.ru/media/pereslavl2008.pdf стр. 28 стр. 51 http://heap.altlinux.org/pereslavl2007/yakshin/abstract.html http://heap.altlinux.org/pereslavl2007/kotegov/abstract.html
(вообще покопать в направлении SOA+DSL+УМД)

O_o ....SOA?

Он умрёт ещё на стадии проектирования сервисной шины (ESB), с её посредническими функциями, и маршрутизации на основе обеспечения качестка услуг (QoS), не говоря уже о службах виртуализации ресурсов...

Или это была реклама WebSphere Application Server?

из ESB для задачи нужен минимум для хранилища данных. Хотя бы чисто концептуально, каркас осилил бы, а там можно и по запчастям сделать на JBoss+ "ESB ручками+"напильник.

Вообще WSAS довольно громоздкий. Но SOA как концепция -- вполне годится.

Как архитектура -- SOA замечательна, для больших задач.

Однако, зачем ему может понадобиться архитектура, предназначенная для On Demand Operating Enviroment, в трактовке его проблемы? Всё, что ему, пока, нужно, это "адаптеры", которые ему лень писать самому. Он _не_ проектирует систему a`la Business On Demand.

> зачем ему может понадобиться архитектура, предназначенная для

для расширяемости. Зацепление модулей слабое, сервисы в SOA ортогональны. При добавлении нового сервиса как новой функциональности не придётся переписывать старый код.

> Всё, что ему, пока, нужно, это "адаптеры"

адаптеры+унифицированное формат с метаданными в хранилище, да, хватит.

> это "адаптеры", которые ему лень писать самому

tracker же как-то индексирует файлы. Может проще хук на плагины к трекеру написать, чтобы ложил метаданные в хранилище. А самому формат не разбирать, это сделает tracker/lucene/strigi/beagle/что там ещё .

Спасибо всем за ответы!!!

От оракла отказались, в пользу Postgres. Postgres оказался в разы быстрее...

SOA сложная штука какая-то, и мало чего в ней понятного.

FUSE имеется ввиду Filesystem in Userspace или SOA??