В случае с с ортировкой можно реализовть подобное, все пехнуть в 1 файл и в начале заголовок, тут начинается все относящееся к букве А, тут к букве Б и т д....

cosc
А добавлять записи как?

Леголегс

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

cosc
Это ещё сильно повезёт, если отыщется функция finsert() а скорее всего будет только fwrite() которая пишет поверх, а "растягивать" файл придётся вручную.

От чего хотели уйти к тому и приходим. В Risearch именно то о чем вы сейчас говорите.
Тогда отсается просто вернуть его и все. Пока мне в голову больше ничего не лезет.

Я до конца так и не разобрался с Risearch, но там практически то же самое что вы все предлагаете. за исключением того что там все это дело упаковывается и в fseek передаются значения согласно упаковке поискового слова.
Собственно можно оставить этот скрипт, поправив его баги. Но полноценного поиска не получится. О причинах я писал в самом начале этой темы.
К варианту поиска по тексту всей темы я обратился только из-за более точного поиска, нежели в Risearch.
Вобщем надо думать.

Что и сортировка там есть? Надо же, значит идея неплохая...
Перечитал 1 пост темы. Если я правильно понял, у Risearch два главных недостатка:
1. Неточный поиск.
2. Невозможность добавления туда слов при ответах или редактировании постов.
В принципе наверно можно эти недостатки исправить, только не знаю насколько реально это все будет реализовать на пхп...
1. Насчет неточного поиска ну тут надо просто подправить его, что бы он в базу ложил не целые темы, а разделял их на конкретные сообщения и соответсвтенно поиск велся по сообщениям. Кроме того, нужно при поиске по AND если в каком-то посте найдены все слова фразы, еще взять этот пост из базы форума и проверить, есть ли в нем действительно все эти слова..
2. Ну вот с этим я не знаю, но было бы неплохо это все-таки осуществить... Возможно надо изменить саму базу индексов, что бы можно было добавлять отдельные слова....
(Добавление)
Чисто теоретически думаю такое возможно, ведь в Mysql, состоящей из целых файлов можно же добавлять отдельные записи и в середину БД...

И главное очень сложная запутанная структура хранения индексов.

Я же уже писал, забудьте об этом. Поймите топик это единое целое. Просто предствьте что топик это пересказ общения нескольких людей на одном листе:
Пример:
cosc:Привет!
TvoyWeb:О, привет
Леголегс:Мужики. а в что тут делаете?

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

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


н-да, сочувствую... Обычно хорошо понятно тогда, когда ты это сам делаешь....
Ну а если заново поиск делать, то ИМХО лучшим вариантом использовать сортировку, так как она позволяет перерывать не всяю БД, а только ее часть....

(шепотом)может первую версию со старым поиском выпустить, и поиск сделать к следующей версии?