можно взять berkley db как физический слой. то есть с помощью неё хранить данные. она по сути - реализация хеша на диске. то есть у тебя есть набор идентификаторов которым соответствуют данные. ты можешь запихнуть новые данные и получить идентификатор или удалить/изменить/вытащить данные по идентификатору. ну и разумеется получить все идентификаторы.

но в принципе писать аналогичную фиговину - делать нечего, можно и с нуля.

Сходи на sql.ru
Там тебя просветят по полной программе :)

Уже. Я и туда запостил. Но ведь на ЛОР всегда есть специалисты почти изо всех областей науки :)

Хм, сделать такую фиговину не сложно. Сложно оптимизировать ее, когда размер базы на винте вырастет до 10-50 гигобайт...

это уже другой разговор. если будут более-менее сложные запросы - возьми лучше mysql. и поменяй спецификацию задачи так чтобы оно в способности mysql влезло. данных оно много хранить может.

> заказчик почему-то настаивает на XML

Заказчик, как известно, всегда неправ по определению, и задача разработчика - грамотно это ему втолковать.

Разработчик тоже неправ.

Клиент, конечно, всегда неправ, потому что в отличие от разработчика не является специалистом в вопросе, потому и обращается за помощью. Но! Может быть надо чётче понять нужды заказчика? Почему он настаивает на XML? Может быть он знаком с (несомненно верным) мнением Ганса Рейзера "Если вы используете допольнительный слой для хранения данных, у вас просто плохая файловая система." Может быть заказчику не так важна скорость, сколько гибкость, изменяемость, мутируемость системы? Прежде конопатить заказчику мозги с высоты своего профессионального роста может лучше разобраться что заказчику нужно? Может он сам попросит в бинарном виде хранить.

А вообще, тему надо переместить в Development.

Есть XML db, http://www.oracle.com/technology/tech/xml/xmldb/index.html

Кратко о задачи. Есть дофига файлов с текстовой информацией. Надо их проиндексировать и осуществлять по ним поиск. Вся информация о файле и метаданные, связанные с ним, хранится в XML - это удобно, человек может посмотреть, отредактировать.

Но словарь, а также список слов из словаря, принадлежащих каждому файлу хранить в XML - это извращение. Там же избыточность огромная будет!

А можете подсказать ссылки на различные сравнения баз данных по скорости/ресурсоемкости?

Плюс Berkley DB в том, что она часто уже есть на машине (входит в дистрибутив). Хотя, конечно, не смертельно поставить и другую СУБД.

Бенчмарк бенчмарку рознь.

> А можете подсказать ссылки на различные сравнения баз данных по скорости/ресурсоемкости?

Есть три вида лжи: статистика, цитирование и бенчмарки.

хм, ну заказчика же надо как-то убедить, что это довольно расточительно и медленно - хранить все в xml

Почему все советуют использовать этот анахронизм BerkeleyDB? Особенно, если требуется доступ из Java. Есть же "родные" Java-движки - как минимум на ум приходит Apache Derby (хотя она и не GPL, но все равно свободная), HypersonicSQL. Наверняка есть и другие - я не спец по Java. У многих свободных СУБД есть JDBC-драйверы (Postgres, SQLite).

> Есть дофига файлов с текстовой информацией. Надо их проиндексировать и осуществлять по ним поиск.

Чем не устроил mnogosearch?

P.S. СУБД в XML есть на www.apache.org

ну вот почему ты считаешь что xml db должны хранить xml в тектовом виде который нужно парсить, а не в бинарном специально приспособленном ?

>mnogosearch?

релевантность хреново вычисляет.

xml db конечно же предназначены для выборки xml данных, те под специальные xmlные задачи(если не ошибаюсь), у тебя же задача явно не xml-льная а реляционная. т.е. если заказчик хочет на выходе бызы получать хмл - то предоставь ему такую возможность, вместо таблицы на селект - xml таблица в тексте ;), также можно предоставить експорт/импорт бызы в xml. других мест для xml я придумать здесь не могу;)

>Где почитать о том, какие существуют структуры данных для хранения информации и быстрого к ней доступа? А также какие наиболее эффективные алгоритмы поиска по таким структурам?

Кнут. Алгоритмы и структуры данных. 3 тома. Лежит везде.

Вот для затравки в соседнем флейме дали: http://infolab.stanford.edu/~backrub/google.html

Если был существовал в природе универсальный оптимальный алгоритм поиска в тексте на любом языке, уж не думаешь ли ты что уже бы кто-нибудь не сделал GPL-ную либу? Ее бы сделали, и программистов бы чтобы ее написать по-новой, не нанимали бы. В каждом конкретном случае программисту приходится напрягаться, и если одному что-то в каком-то случае подошло, он с тобой этой информацией не поделится, это все равно что ключи тебе от квартиры отдать. Он работу тогда потеряет. Квалификация - это единственный капитал, который позволяет программисту зарабатывать, продавая квалификацию.

>заказчик почему-то настаивает на XML - как формате для хранения проиндексированных данных и словаря.

п.1 На хуй заказчика. А на лиспе он тебя писать не просит?

>мне нужно побольше почитать про форматы хранения и алгоритмы поиска.

XML не формат хранения данных ни разу. Если заказчик туп настолько что этого не понимает, ст. п.1

>Уже. Я и туда запостил.

Эт http://www.sql.ru/forum/actualthread.aspx?bid=34&tid=239050 чтоли?

>Но ведь на ЛОР всегда есть специалисты почти изо всех областей науки :)

vsl ушел и они ушли. Ибо читать вендекапец ждемебилдов надоедает. Модераторы сами не понимают, что из качественного форума превратили LOR в помойку. Совок однако в чистом виде.

>Есть дофига файлов с текстовой информацией. Надо их проиндексировать и осуществлять по ним поиск.

Текстовых файлов? Или файлов Document Word с текстовой информацией?

об иерархических БД ничего не слышал ?

>об иерархических БД ничего не слышал ?

Читал на sql.ru, что они утонули в своем собственном г.не. Конкретно, у любого тупля может быть только один предок. Поэтому над ними невозможно применять математические операции, как надо множествами в реляционках

По сабжу: почему не поинтересоваться готовыми бесплатными разработками? Может тебя в долю возьмут? www.solarix.ru/index-ru.shtml например

>Читал на sql.ru, что они утонули в своем собственном

у них всё равно есть свой юзе-кейс, и xml-db это их реинкарнация ...

Вызывающе неверная информация.

> Кнут. Алгоритмы и структуры данных. 3 тома. Лежит везде.

Учите матчасть. Книжку "Алгоритмы и структуры данных" написал Никлаус Вирт, Дональд Кнут написал три тома "Искусства программирования."

> если заказчик хочет на выходе бызы получать хмл - то предоставь ему такую возможность, вместо таблицы на селект - xml таблица в тексте ;), также можно предоставить експорт/импорт бызы в xml. других мест для xml я придумать здесь не могу

Хорошо сказано.

>Книжку "Алгоритмы и структуры данных" написал Никлаус Вирт, Дональд Кнут написал три тома "Искусства программирования."

к реляционным базам это имеет отношение как арифметика к анализу.