Fin, что-то я совсем запутался, каким образом тогда представляется индекс какого-либо документа???

Что бы было быстро пиши Хеширование, с если еще и место хочешь экономить, то двоичное дерево полюбому.

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

тэкс, народ, наконец выкроил немного времени, по своим сооброжениям и алгоритмам, опираясь на вычитанный материал, разработал структуру индекса БД и методы быстрой выборки в ней, в итоге в тестовой БД на 20ГБ текста, мой рабочий комп выполняет поиск документов (200 тыс мнимых файлов)... ну достаточно быстро, до секунды занимает поиск, для моих целей даже минута не проблема, так что с этим моментом все ясно, спасибо за помощь

сейчас вот осталась только одна маленькая проблемка: поиск производится по каждому слову в отдельности т.е. если в поисковом запросе, например, 5 слов - это 5 независимых поисков по каждому из слов, там выходит очень длинный, но достаточно быстрый sql запрос, который производит выборку соответствующих id документов, в общем он нас не интересует и его можно принять, например, как SELECT id FROM indx WHERE `dat`='bla-bla-bla' так вот проблема в том, что по запросу "слово1 слово2 слово3 слово4 слово5" нужно сортировать документы в порядке убывания количества/порядка слов

если произвести выборку id (а также позиции запроса в документе, это тоже важно) и потом анализируя эти данные производить сортировку документов, комп уходит в даун и завершения я так и не дожидался - ресурсы памяти и проца сжираются мигом

но так как наш sql запросы для выборки id документа независимы друг от друга, мы запросто можем объеденить их в один огромный запрос и впихнуть туда сортировку документов, вот только как это сделать ума не приложу

или есть другой путь?

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

в общем я опять в полном тупике, буду благодарен за любую помощь и подсказки

По каждому слову у тебя будет какой то массив индексов так? Ну в чем же дело. Тут уже алгорит слияния массивов. Сначало отсортировываеш все массивы. потом начиная с первых членов массива, идеш вверх по массивам и смотриш соответствия всех документов.
Например:
В первом запросе получился массив индексов
2 7 25 64 188 269 365
2 8 26 64 189 282 365

Тут не трудно заметить, что в документе под индексов 2 64 365 есть сразу два слова.

Кстати, чтобы быстрее искать слово, можно создать для него автомат и тогда сложность поиска станет O(n)

SoWa, спасибо, с этим уже проблем нет

Fin, по результатам эксперемента по среднему запросу получали массив на 20 тыс элементов
опять же, даже при 5 словах в запросе это уже 5 массивов и нам надо же провести довольно много сравнений: документ входит во все 5 сассивов, в один из 4-х (это уже не одна проверка ;)), 3-х, 2-х и т.д.

кроме того специфика там такая, что запросы все будут длинными, 5 слов это минимум

в общем можно и массивами, сегодня погонял на их сервере, довольно шустро, но это очень ресурсоемко выходит, думаю, можно было бы как-то организовать, чтобы после sql запроса уже получать отсортированные данные, вот только как, пока не ясно

PROme2 Первое. Как ты организовал все таки поиск? Чтобы от этого можно было плясать.
Второе, Когда индексируеш документ, индексы в словах нужно сортировать сразу. Тогда все индексы по слову будут выходить в отсортированном порядке.
Да кстати, есть алгоритм битовой сортировки. Он является самым быстрым алгоритмом сортировки. Единственный недостаток его, нужно все время настраивать его на данные. Когда я эксперементировал с ним, у меня были следуюшие результаты. На Pentium III 850 Мгц, массив из 1 миллиона 32 байтных значений, алгоритм сортировал примерно за 28 секунд. При этом я алгоритм не слишком оптимизировал. Количество полных проходов данного алгоритма по массиву будет равно количеству бит в числе, по которому идет сортировка.