крамольный вопрос про "инвертированные файлы"

euhenio, - честно, - не понял: если (позицию слова в блоке) мы не храним (храним: (№ документа, № блока в документе)), - то как мы сможем ее "испрользовать при более хитрых запросах с участием расстояний"?

Тьфу, блин, блоки относились не к обратному индексу, а восстановлению текста... :) А я-то думал...

!Иван FXS, ну, если в отдельном индексе их (позиции) хранить. Тут ведь от задачи исходим - если тебе, например, требуется быстрый поиск документов, содержащих слова - то позиции слов хранить вообще не обязательно. Если ты по умолчанию ищешь в пределах предложения - можно хранить номер предложения.

А разве рационально - с точки зрения ресурсов - хранить несколько индексов (один - для "быстрого поиска", другой - для "подробного")?

Неужели кто-то так делает??

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

Что такое "прямой индекс", сорри?

Это - если словарь:

101 мама

...

245 мыла

...

896 раму

и каталог документов:

...

19876 "про маму"

...

- то прямой индекс:

19876 1 101

...

19876 2 245

...

19876 3 896

Так?

!Иван FXS,

Выражу свое понимание.

Прямой индекс - это индексация по ключу. Как в любой БД. "инвертированный", если я могу тут правильно выразиться - это просто список, сгенерированный из прямого. Обычно это какой-то типизированный файл (ну, или кучка файлов :) ), а что в том файле записано - уже волеизъявление программера (не обязательно ведь то, что было записано в прямом индексе, что-то добавляетcя, видоизменяется и т. д.). По понятным причинам, работать с таким файлом - гораздо быстрее, чем с выборками из таблиц.

Посмотрите примерно тут (не знаю, давали ли уже эту ссылку):

http://old.company.yandex.ru/articles/article10.html