|
ru.cgi.perl
- RU.CGI.PERL ------------------------------------------------------------------
From : Ruslan Bondarev 2:4624/1.65 12 Feb 2001 21:59:42
To : Tarasov Sergej
Subject : Re: Постраничный вывод
--------------------------------------------------------------------------------
Понедельник Февраль 12 2001 13:01, Tarasov Sergej -> Ruslan Bondarev:
TS> данных все это будет проделано еще раз??? Или все же это где-либо
TS> сохраняется. И индексирование здесь ни при чем.
TS> Если база позволяет сохранять результаты между вызовами -
TS> замечательно. А если нет, и полный запрос выполняется достаточно долго
TS> (а даже такие монстры, как Google первичный запрос могут выполнять
TS> более секунды, а последующие на порядок быстрее), то сохранение
TS> конечного результата может значительно ускорить дело.
А теперь почитай свой рецепт:
From: "Tarasov Sergej" <tarasov@pmi.lv>
При первом запросе база возвращает массив ID записей,
удовлетворяющих запросу. Мы их сортируем, находим пересечение множеств
для сложных запросов и т.п. Затем пишем их во временный файл.
А в выводе результатов для каждой страницы указываем не только
с какой записи нужно начинать, но и имя временного файла.
Затем, при запросе следующей страницы, если скрипт видит, что
в запросе присутствует имя файла, он берет список ID оттуда
и запрашивает у базы только нужные 20 записей по их ID.
Если же имени файла в запросе нет, вся работа проделывается
полностью с самого начала. А раз в сутки все временные файлы
удаляются.
=== End of msg ===
А теперь скажи мне, что лучше - создавать для каждого запроса свой временный
файл и затем заставлять одного пользователя с ним работать или создавать один
файл на ВСЕХ пользователей, задавших этот запрос?
То есть, если у тебя на основании запроса А выдается ответ В, то выдавать
результат В всем, кто запрашивает запрос А. Причем ответ В пре-кешируется и
хранится, а не удаляется как только юзер закончил скроллинг базы. Если ты
расказывал о таком кешировании - то да, я согласен - это круто (местами). А если
ты просто из одной базы строишь другую (причем переносишь ее в файл) и
(наверное) при вызове пользуешься angle-operator ("<>"), а не seek'аешь по файлу
с полями фиксированной длины - это, наверное, совсем не круто.
Я может и заблуждаюсь в своем мировоззрении, если что - поправь. (о;
Да и вообще, ты что, Гугль свой пишешь, чтоль? Я же говорил, что при простом
индексировании ключевого поля и не очень сложном пересечении мне сдвиг и LIMIT
хватало выше крыши. Hе хватало бы - сказал бы директору проекта, чтобы он
прикупил какой-нить Оракл или Информикс для этой задачи.
... bye.
--- What can change the nature of a man?..
* Origin: (2:4624/1.65)
Вернуться к списку тем, сортированных по: возрастание даты уменьшение даты тема автор
|
