Работаю на Delphi 6, использую БД Paradox. Нужно реализовать полнотекстовый индексированный поиск по БД (по строковым и мемо полям). Какие решения существуют? Если переход на другую БД существенно упростит решение, я готов рассмотреть и этот вариант. Поделитесь опытом, пожалуйста. Речь идет о новом православном проекте. Буду рад, если кто из программистов предложит сотрудничество.

                

Если не найдете ничего уже готового, могу лишь описать решение, как сделать подобный поиск на любой СУБД самому, ручками. Решение состоит в создании нескольких дополнительных таблиц, хранящих подстроки книг и ссылки на нужные места. Некоторые поля этих таблиц индексируются, что обеспечивает быстрый поиск. Вашей задачей будет поддержание этих таблиц-"индексов" в актуальном виде: при добавлении новой книги дополнять таблицы новыми подстроками и ссылками, при удалении -- удалять уже ненужные записи, при модификации ... ну, чтоб не мучиться, на первых порах удалять и добавлять заново.

Структура и содержимое "индексных" таблиц зависит от тех задач, которые Вы хотите поставить перед поисковым алгоритмом. Если задачу ставить в лоб -- поиск по любой подстроке любой длины -- то размер индекса для одной книги будет пропорционален квадрату длины книги (речь не о размере переплета . Но обычно никому не нужен поиск по подстрокам размером с килобайт, так что...

Вот несколько примеров.

1. Поиск ведется по отдельным словам (словоформам). Создаем две таблицы, со словоформами и ссылками:

create table SubStrings (ID number primary key, SubString varchar2 (100));
create index on SubStrings (SubString);
create table Refs (ID number primary key, SubString_ID number, Book_ID number, OffsetInBook number);
create index on Refs (SubString_ID);
create index on Refs (Book_ID);

При добавлении новой книги обогащаем таблицу SubStrings новыми словами, а таблицу Refs -- всеми ссылками на каждое из слов. Если слово уже присутствует в SubStrings, мы его туда не добавляем, однако все ссылки на него все же прописываем.

При удалении книги удаляем все записи из Refs с Book_ID удаляемой книги, и все записи из SubStrings, на которые больше нет ссылок из Refs.

Поиск состоит в нахождении нужного слова в поле SubStrings.SubString и выводе всех ссылок на него. Чтобы поиск был быстрым, это поле проиндексировано средствами СУБД.

2. Поиск по подстроке размера от m до n. Структура таблиц та же. При добавлении книги обогащаем SubStrings всеми новыми встретившимися подстроками от m до n. Да, да, ручками, это не так уж сложно, как может показаться на первый взгляд, и не такого уж большого размера вследствие статистической природы языков. А ссылки дополняем ссылками на эти подстроки, и вот этого материала будет очень много, так что соразмеряйте ограничения m и n. Удаление книги и поиск аналогичны п.1.

3. Поиск только по словам и по группе слов.

Идея -- создать третью таблицу с цепочками слов (разумеется, в виде ID). Здесь возможны несколько решений. Неэкономичное, но простое и наглядное решение:

Пусть поиск ограничен N словами.

create table SubStrings (ID number primary key, SubString varchar2 (100));
create index on SubStrings (SubString);
create table WordSeries (ID number primary key, SubString1_ID number, SubString2_ID number, ... , SubStringN_ID number);
create index on WordSeries (SubString1_ID, SubString2_ID); -- больше и не надо
create table Refs (ID number primary key, WordSeries_ID number, Book_ID number, OffsetInBook number);
create index on Refs (WordSeries_ID);
create index on Refs (Book_ID);

Конструкция "..." наводит на мысли, но я не обещал, что решение красивое. Оно простое и наглядное.

Вставка книги. Таблицу SubStrings забиваем новыми словами, таблицу WordSeries -- новыми цепочками слов (в виде ссылок на слова, ненужные ID заполняем нулями), Refs -- ссылками на текст.

Удаление здесь более сложное. Долго писать, но при желании можно воплотить.

Поиск. Введенные пользователем слова отыскиваются в SubStrings (если хоть одного нет, выходим), далее ищется нужная цепочка (или начало цепочки, все зависит от того, как мы заполняли WordSeries, полными сериями, или сериями всех возможных размеров от 1 до N). Ссылки поступают в дальнейшую обработку.

Непростое, но более бережливое и общее решение состоит в построении цепочек слов в виде линейных списков. Вероятно, возможны и иные решения.

Уф. Ну, если найдете готовый механизм, то хоть будете представлять, как такие индексы устроены.

                

Большое спасибо! Кое-что я себе представлял, но не так глубоко, теперь есть почва для размышлений. Конечно, хотелось бы воспользоваться готовым модулем, особенно если он окажется с учетом русских словоформ, но поскольку такового не найдено пока, будем думать дальше в сторону своей разработки. Спасибо!

                

Не по теме, извините, вопрос Буквариусу
Какой редактор шрифтов можете посоветовать? Если есть ссылки на учебники по этому делу - тоже буду очень благодарен.

                

Сомневаюсь, что смогу посоветовать типичный набор для редактирования, ибо с профессионалами мне общаться не пришлось.

В моей технологической цепочке используется два редактора: старый Fontographer 3.5.2 и относительно новый Fontlab 4.0.5. Fontographer я использую для рисования контуров, ибо, на мой взгляд, этот редактор обладает наиболее удобным для этой цели редактором, несмотря на все его глюки и на огромное богатство FontLab. Возможно, дело привычки. Несколько раз пробовал серьезно освоить редактор контуров FontLab-а, но отчаивался и бросал. Криво и неудобно, но это сугубое имхо. Необходим именно 3.5.2, ибо в Fontographer 4.1 редактор изменился и стал намного хуже. Короче, типичный синдром брюзги, но меня устраивает.

Fontographer 3.5.2 годится только для рисования контуров, ибо во всех остальных отношениях он безнадежно устарел. Программа вообще написана под интерфейс Win 3.x. В общем, полученные контура (на произвольных символьных местах) я экспортирую в Type1-шрифт и загружаю в FontLab. Здесь я с нуля создаю новый шрифтовой проект, заполняю его всеми необходимыми сведениями и переношу на нужные места контуры из импортированного Type1-шрифта. На этом роль промежуточного шрифта заканчивается.

FontLab - это лучший шрифтовой редактор по всем показателям (ну, для меня - кроме редактора контуров). На сегодня нет иного средства, столь тонко и всеобъемлюще работающего со шрифтами во многих их особенностях. В последней, 4.5.3, версии появились даже возможности создавать шрифты с серьезными возможностями в области OpenType (использовать их, правда, пока почти негде). Плюс, если его возможностей мало, можно писать свои собственные расширения на Python.

Жаль, цена у него кусачая.

В этом редакторе я делаю все остальное и компилирую конечный пакет шрифтов.

Ссылок на учебники я не знаю, не искал. В магазинах куча литературы. Правда, серьезного мне не попадалось. К FontLab прилагается PDF с инструкцией (свободно скачивается с сайта, www.fontlab.com), на английском. Инструкция большая и толковая. Диалект - класса "русский программер пишет инструкцию на английском", так что особых трудностей в прочтении не вызывает, ход мыслей все равно родной и близкий.

Если не найдете в сети этих редакторов... Ну, напишите мне на мыло, подумаем.

                

Спасибо. Попробую нарыть и разобраться.
Есть мысль - свой Minipics.oet +CSS + немного JavaScript- может оказаться очень интересно и компактно.
Если что хорошее получится - обязательно напишу - это многим может понадобится - но не скоро, очень не скоро

                

А обязательно ли Дельфи использовать? Такие вещи, ИМХО, лучше на PERL'е. Или, если без VCL не обойтись, то на С++ Builder.
(Вообще, если без Дельфи не обойтись, то лучше работать на 3 версии. Она и быстрее, и exe меньше получаются)

                

StanB., Вы писали:
> А обязательно ли Дельфи использовать? Такие вещи, ИМХО, лучше на PERL'е. Или, если без VCL не обойтись, то на С++ Builder.

Нет, создается обычная программа для Windows. С С++ Builder я, к сожалению, мало знаком, проект займет больше времени и больше будет багов.

> (Вообще, если без Дельфи не обойтись, то лучше работать на 3 версии. Она и быстрее, и exe меньше получаются)

В данном случае речь не об этом. А о возможных вариантах полнотекстового поиска, т.е. об алгоритмах. Если не найду оптимального решения, то придется поиск пока не реализовывать, для проекта это не смертельно, хотя с ним будет значительно удобнее.

                

Саша, а полнотекстовый это какой поиск, то есть чтобы можно было строку переменной длины найти в базе данных?!
Я если често с дбазами наддных на Билдере хоть и имел дело но не занимался поисками строк, я посоветую этот спросить тут faq.pp.ru.

                

> Саша, а полнотекстовый это какой поиск, то есть чтобы можно было строку переменной длины найти в базе данных?!

Да, именно так.

> Я если често с дбазами наддных на Билдере хоть и имел дело но не занимался поисками строк, я посоветую этот спросить тут faq.pp.ru.

Это понятно, когда прижмет, пройдусь по популярным тех.форумам, поспрашиваю. Просто я надеялся, что кто-то из местных умельцев отыщется. Спасибо за ссылку!

                

Александр Иванов, Вы писали:

> Да, именно так.
Насколько я помню на парадоксе дейтсвительно не сделать такой поиск, но это только насколько я помню. А вообще очень хорошая БД mysql, компоненты доступа к ней из Билдера правда платны, хотя может щас уже и есть бесплатные, также есть для Билдера БД firebird с бесплатными компонентами, я думаю (не знаю, а именно думаю), что она имеет такою возможность. С BDE лучше не связываться, ввиду сложных настроек в BDE администраторе. Есть еще БД Interbase и Midas, но о них я знаю очень мало.

> Это понятно, когда прижмет, пройдусь по популярным тех.форумам, поспрашиваю. Просто я надеялся, что кто-то из местных умельцев отыщется. Спасибо за ссылку!
Не за что, это я типа свой форум рекламирую!))))))))))

                

Александр Иванов, Вы писали:
>Речь идет о новом православном

Случайно, не православный календарь?

                

> Случайно, не православный календарь?

Нет.