СтуденточкаСобственно вопрос не в том как найти, а как найти быстрее!
Например, в фоксе делается просто LOCATE FOR ...
Однако в других базах данных начинается надо зачем то делать SELECT SQL ...
Вопрос:
В фоксе есть понятие Pointer "Там где я стою" - Отуда и беру.
Почему этого понятия нет в крутых субд?
При работе с таблицами DBF, Вы, фактически, обращаетесь напрямую к таблице. Это некий аналог чтения текстового файла. Естественно, Вы точно знаете, где именно Вы "стоите". Какое именно место файла "читаете".

А вот при работе с "промышленными" СУБД прямого доступа к файлу данных у Вас нет. Совсем нет! Более того, прямого доступа к файлу данных вообще никто не имеет. "Взрослые" СУБД - это всегда "два-в-одном". Во-первых, конечно, собственно данные, а, во-вторых, некое приложение (драйвер, служба, утилита и т.п.) которая как раз и обеспечивает доступ к этим данным. Вы никак, никоим образом, не можете обратится напрямую к файлу данных. Только и исключительно через приложение-посредник.

Данные всегда "закрыты" неким "защитником" ("хранителем", "джинном", "библиотекарем"). Взаимоотношения любого пользователя с промышленной СУБД можно представить как постоянные запросы этому самому "джинну": Не будет ли любезен, многоуважаемый джинн... А уж сам "джинн" решит будет ли он "любезен"

Обратите внимание, что в данном случае "библиотекарь" книгу Вам в руки не даст. Никогда и ни при каких условиях. Максимум, что Вы можете получить - это некую копию. Выборку. Результат работы Select-SQL.

Теперь вопрос Вам. Как именно при такой организации работы Вы предполагаете чисто физически определять где именно Вы стоите? Т.е. вот Вы разработчик "промышленной" СУБД. Как будете определять "где я стою"? ЧТО должен "запомнить" этот самый "джинн" ("библиотекарь")? Каким образом идентифицировать "текущее положение"?

СтуденточкаНичего умнее не придумали кроме как долбаный SELECT SQL?
А какие у Вас претензии к Select-SQL? Что именно не нравится?

СтуденточкаУ фоксовской базы может быть тысячи пользователей, но есть понятие Pointer - указатель записи.
У каждого пользователя БД свой Pointer и даже несколько поинтеров для каждой таблицы!
Еще раз напомню, что к файлам DBF Вы обращаетесь как к текстовому файлу. Естественно, у Вас всегда есть некое "текущее положение". К промышленным СУБД Вы посылаете запрос с просьбой предоставить некую выборку. Некую копию данных. Как следствие, у Вас нет и не может быть "текущего" положения. Вы же не знаете из какого именно места данных была получена выборка.

СтуденточкаSEEK работает медленнее чем LOCATE,
Мда... Это Вас кто-то жестоко обманул.

Ну, представьте, что у Вас есть некая книга (файл DBF). Вам надо найти некую главу в этой книге. У Вас есть два варианта поиска

1. Последовательно перелистывать страницу за страницей, пока не найдете искомую главу
2. Если у книги есть оглавление (индекс), то найти нужную главу в оглавлении и сразу перейти к нужной странице без перелистывания всех страниц книги

Так вот, LOCATE работает по первому варианту, а SEEK - по второму. Вы серьезно думаете, что поиск перебором быстрее, чем поиск по оглавлению?

Разумеется, поиск по оглавлению работает только и исключительно при наличии этого самого оглавления. Т.е. при наличии индекса. Нет индекса и использование SEEK - невозможно. Только Locate

Студенточкатак как SEEK работает при включённом SET ORDER ...
Обратите внимание, что кроме команды SEEK для которой действительно нужна настройка SET ORDER, есть еще и одноименная функция SEEK() для которой настройка SET ORDER не обязательна. Хотя обязательным является факт наличия необходимого индекса.

СтуденточкаВ описании оптимизатора Rushmore чётко и ясно сказано - SET ORDER замедляет работу Rushmore оптимизатора.
В документации рекомендуют все SET ORDER отключать для максимально быстрого поиска.
Здесь опять надо начать издалека. Есть такая аксиома: Данные хранятся не так, как они отображаются.

Пользователю в одном случае надо "белый верх, черный низ", а в другом "черный верх, белый низ". Т.е. одна из задач программиста заключается в том, чтобы отобразить данные в некоем виде, удобном для просмотра пользователем. Так вот, настройка SET ORDER именно этим и занимается. Она отображает данные в определенном порядке. Это некая "визуализация" данных.

Но нужна ли "визуализация" для поиска данных? Разумеется нет! Вполне можно обойтись и без нее. Достаточно того, чтобы нужный индекс просто существовал. Делать его главным (SET ORDER) для целей поиска нет никакой необходимости. Т.е., разумеется, можно, но не обязательно.

Более того, "визуализация" неизбежно замедляет поиск, если критерии поиска отличны от критериев "визуализации". Ну, представьте себе, что у Вас есть книга "рассыпанная" на отдельные страницы и оглавление к этой книге. Вам надо найти некий текст. Не главу, а именно текст внутри неизвестно какой главы. SET ORDER вынуждает Вас перебирать листы строго в порядке их нумерации. Т.е. вместо того, чтобы взять первый попавшийся лист и поискать в нем нужный текст, если не нашли, то взять следующий попавшийся лист и т.п., Вы вынуждены сначала в этой куче найти лист с нужным номером и только потом в найденном листе искать текст.

Однако! Повторюсь. Замедление происходит только и исключительно в том случае, если критерии поиска отличны от выражения индекса использованного для SET ORDER. Если Вы будете искать именно по названию главы (по оглавлению), то SET ORDER существенно ускорит поиск.