Хотел предложить тему для обсуждения, любая программа связанная с БД
использует справочники, классификаторы и тому подобное. Для простоты
справочник имеет такую структуру
ID Integer
Descr String
и содержит примерно 20 000 элементов.

Задача состоит в следующем, как создать визуальную форму
справочника организовать там поиск, навигацию, редактирование и т.д.
Дальнейшие рассуждения относятся к Delphi.
Классическим ответом будет: Бросаем на фору TDBGrid, TQuery, TDataSet
в TQuery пишем Select * From TableName Order By Descr, ID и все работает.
Но такой способ подходит разве что для книг по основам Delphi и БД.
Сразу возникаю вопросы, как обновлять такой список (переоткрытие запроса),
как настроится на элемент начинающийся, например, с буквы "Я" (Fetch-ить все до "Я", а скорость ???).
Можно конечно хранить такой справочник в памяти, а если таких справочников 10, 20, 100 или канал передачи данных узкий или количество изменений в справочнике другими пользователями большое.

Я пришел к выводу, что для визуального представления необходимо формировать запрос вида
Select FIRST N * From TableName
Order By Descr, ID (Синтаксис InterBase) где N - это количество строк которое необходимо вернуть.
Если пользователь перемещается на строку ниже, то выполняется запрос вида
Select FIRST 1 * From TableName
Where DESCR>:DESCR or (DESCR=:DESCR and ID>:ID)
Order By Descr, ID ,где :DESCR ,:ID это значения последних элементов предыдущего запроса
в результате такого подхода пользователь получит следующую запись в своем наборе данных

Если я хочу организовать поиск по первым буквам задача сводится к формированию запроса вида
Select FIRST N * From TableName
Where DESCR>=:DESCR
Order By Descr, ID

Соответственно никакого Fetch по 20 000 элементов ненужно сервер вернет
только записи, начинающиеся с DESCR (скорость огромна)

Если я хочу переместиться в конец справочника получаю количество элементов CN
Select Count(*) From TableName
Order By Descr, ID

И

Select FIRST CN-N * From TableName
Order By Descr, ID

Таким образом, задача сводится к написанию компонента, который будет "эмулировать"
поведения TDataSet только держать он в себе будет N элементов которые отображаются
в сетке.

Если у кого ни будь, есть мысли или готовые решения, алгоритмы и т.д. поделитесь ведь
любая БД начинается со справочников.

[Dik76]
Согласен, что при навигации N - необходимо брать > 1 так будет быстрее. Использование
сколера в принципе необязательно для позиционирования на элементе я бы в 99% случаев
воспользовался поиском по первым буквам

[S.G.]
По поводу использования таймера согласен, но использование LIKE лишает
возможности навигации по всему списку т.е. если я накладываю фильтр 'ПЕТ' вижу только
например, фамилии ПЕТРОВ, а вот подняться на букву О уже невозможно список уже нелинейный. А хотелось бы оставить его линейным.

[Ярослав Татаренко]
А вот 3 способа это конечно здорово для книжек, но вот в реальной жизни это слишком сложно
посмотри ради интереса 1C там справочники создаются взмахом руки никаких кэширований и
классификаций, поиск по линейному списку очень очень быстрый.
Что же касается высоких требований к серверу я не думаю что пользователь для поиска
необходимой строки будут скролировать список они просто наберут искомую строку на клавиатуре
а уж SQL сервер сам ее найдет.