Здравствуйте!

Вопрос по проектированию БД - неплохо бы было получить совет от человека, который сталкивался с похожей ситуацией.

Ситуация следующая(объясняю на пальцах): пускай есть некая таблица, например, с городами. Клиент выполнил запрос(пофигу какой - пускай он, скажем, запросил все города России) и в итоге получил идентификаторы, скажем, 100 000 городов.

Результат клиенту предоставляется в виде постраничной навигации(т.е., скажем по 100 городов(идентификаторов) на странице). Вопрос: где хранить эти 100 000 идентификаторов городов пока клиент будет осуществлять навигацию по страницам с результатами?

Вариант 1: выполнять выборку всех городов России(каждый раз по 100 000 результатов) при каждом запросе страницы с результатами(с ипользованием LIMIT(X, Y)) - не рационально с точки зрения рессурсов.

Вариант 2: сохранить эти 100 000 результатов во временную таблицу. Но тут возникает вопрос - сколько такая таблица будет занимать памяти? (ситуация: 20 человек запросили по 100 000 городов, каждому система выделила по временной таблице - судя по всему, количество памяти здесь будет измеряться мегабайтами, что очень много).

Вариант 3: хранить результаты в клиентской сессии(считай - временный файл), но - насколько этот вариант оправдан - я не знаю. Получается, что прийдётся каждый раз парсить содержимое этого файла, а, учитывая, что парсить, опять же, прийдётся эти 100 000 идентификаторов - то это уже накладный расход процессорного времени.

В общем - где хранить БОЛЬШИЕ временные результаты для каждого клиента?

Спасибо!

Ок - спасибо за ответы!

Давайте тогда уточню ситуацию. Клиенту, и правда, нет необходимости работать сразу со 100 000 идентификаторов - поэтому я и организовываю для него постраничный вывод(например, по 100 результатов на страницу - представьте себе результаты в Google или Yandex и вы поймете, что я имею ввиду). При этом я НЕ хочу выполнять, при каждом обращении к очередной странице с результатами, комманду вида: SELECT id from Cities where Country = 'Russia' LIMIT(0, 100); - так как это заставит SQL-сервак каждый раз выбирать все записи соответствующие критерию и отбрасывать часть из них потому, что указан LIMIT. Поэтому я и задумался о "хранении" данных, потому, что не хочу постоянно торбить SQL-сервак одинаковыми запросами с LIMIT'ом.

авторЕсли правильный ответ: сразу не надо,
то подсказка к решению: клиент не сильно расстроится, если при выборке 2 или 10-ой страницы он увидит не 100 процентов те же данные, которые увидел бы там 5 минут назад...

А можно поподробнее?

авторпри листании вперед считывается очереданя порция (100 записей) из БД и записывается в ОП
при листании назад данные берутся из ОП

Ну, так получится описанная мною ситуация? - выполняется запрос с LIMIT'ом, данные помещаются в ОП, потом опять запрос с LIMIТ'ом + данные в ОП - мне это кажется крайне непроизводительным - я не прав?

P.S. По поводу "городов" и.т.п.: города я привел только для примера; на их месте могло быть что угодно: ложки, чашки, обезьяны - я моделирую ситуацию "на пальцах".

авторЗапросы переписывать, чтобы давать более детальные критерии отбора, чтобы они давали меньше данных.

Это хорошо в теории, но тогда как объяснить вариант с той-же поисковой системой, которая выдаёт в результате поиска по ключевому слову, скажем, 1000 000 результатов? (я сейчас не беру в расчёт технические мощности, облачные технологии и прочее). Я и сам не верю, что поисковик где-то временно сохраняет эти 1000 000 результатов пока длится клиентская сессия - но тогда как это организовано? - хочу взять в толк.

Спасибо.

_модЗапрос выполняется один раз, потом строки считываются из курсора (зависит от СУБД)

Спасибо! Я уж было подумал, что это именно то, что мне нужно, пока Кот Матроскин не написал ответ на мой вопрос, который я еще не задал:)) Сохраняется ли курсор между закрытыми соединениями с SQL сервером? (т.е. клиент считал результаты, потом отключился, потом снова подключился(минут через 5) и снова запросил данные по открытому для него курсору).

Если сохраняется - то логичный вопрос - как его закрыть, если клиент "ушел навсегда"? - логично заявление Кота Матроскина о том, что для веба курвсов - это плохая реализация(по понятной причине). Иначе говоря, разумным ли будет вариант написать резиндентную программу(локальную), которая будет отслеживать открытые курсоры и закрывать их?(например, курсоры, которые открыты более 20 минут назад). Я понимаю, что это извращение, но, если нет других вариантов, то почему бы и нет? - это, в любом случае, мнее требовательно к рессурсам чем повторные запросы с LIMIT'ом.

CawaSPbВычитывать и хранить ID на первые 10 (обобщённо) страниц результата.
Фактически для пользователя для "росмотра глазами" (для чего и организуется постраничный вывод) 51-я, 106-я и 107-я страницы результата идентичны (==вовсе не нужны).

Черт возьми! А это ведь и правда решение, до которого я, какого-то хрена, сам додуматься не мог! Сам же видел на сайтах кнопочку по типу "смотреть еще результаты" - эта кнопочка-то и отправляет повторный запрос SQL-серваку! И незачем кешировать все и сразу - можно закешировать только, скажем, первых 10 страниц(т.е. около 100 - 1000 результатов!).

Это ОНО! Спасибо