Разработка приложений баз данных с помощью API InterBase.

Как было упомянуто выше, правильное использование специализированных компонент ставит их по производительности практически на одну ступень с вызовами API выбранной СУБД. На мой взгляд, использование API оправданно в том редком случае, когда возможностей даже специфических компонент для разработки недостаточно, хотя это и крайне маловероятно, или если для платформы, под которую ведется разработка, такие компоненты отсутствуют (Sun Solaris). Создание запросов к базе данных. Выбрав стратегию доступа к данным и определившись с архитектурой приложения, можно обратить внимание на то, каким образом мы собираемся их использовать. Главное правило состоит в том, что чем меньше вы запрашиваете данных у сервера, тем быстрее будет работать ваше приложение. Конечно, запрашивать у сервера меньше данных, чем пользователь хочет увидеть за один раз, нерационально, поэтому первым вопросом должен быть "какие данные необходимы для каждого модуля системы?" Разработчикам, переходящим с настольных баз данных, требуется перебороть в себе таблично ориентированное представление о базах данных. База InterBase, несомненно, содержит таблицы. Но при проектировании программы вы их не видите, вы видите только результат выполнения запроса SQL. Можно, конечно, написать запрос, который возвращает все записи из таблицы (по крайней мере, видимые для данной транзакции):

Но в большинстве случаев такой запрос вернет значительно больше данных, чем это требуется для оптимальной работы пользовательского интерфейса и обработки бизнес-процессов. Подобный запрос, кстати, не использует такие полезные особенности InterBase/ Firebird, как возможность объединения (JOIN) и сортировки (ORDER BY) результирующего набора данных.

Запрашиваете меньше данных — получаете большую скорость. Для осуществления определенных задач в программе вам могут быть не нужны все столбцы таблицы. Фактически не стоит часто использовать знак "*" в запросах выборки, лучше использовать прямое перечисление полей. Подобный способ основывается на том, что даже если мне нужны все столбцы таблицы, мне не нужны столбцы таблицы, которые будут добавлены в будущем, когда я завершу эту часть программы. Определение конкретных столбцов в запросе гарантирует, что я получу только те столбцы, которые я заявил в запросе, даже если структура таблицы будет развиваться дальше. Аналогично даже если пользователь действительно нуждается во всех без исключения записях из таблицы, ему необязательно видеть их все в один момент времени. Пользователю может быть крайне неудобно искать поля в середине сетки данных в таблице с количеством записей выше среднего. Скажем, если у вас в таблице более 100 записей, вам уже следует основательно подумать над дизайном вашего приложения.
К чему все это сводится? Вот к чему: чем меньше вы запрашиваете и пересылаете данных, тем быстрее ваше приложение будет работать, даже на не очень скоростных сетях. Вот несколько прикладных методов, которые вы можете использовать для уменьшения количества выбираемых (SELECT) данных.

Обеспечьте пользователю хорошие инструментальные средства для поиска записей, которые его интересуют. Если список слишком велик, чтобы отображать его в единственном неразрывном виде, разбейте его на логические страницы с табуляцией по первым буквам от "А" до "Я". Если и в этом случае списки получаются слишком длинными, предоставьте пользователю мощные средства фильтрации данных для сужения полученного в результате применения фильтра множества записей. Для реализации поиска данных в приложении вы можете взять на вооружение методы, используемые для поиска web-страниц. Когда пользователю выдается набор записей, даже если он сравнительно небольшой, достаточно использовать одно-два ключевых поля для формирования фильтра запроса. Пусть в приложении будет отдельное окно или часть окна, где пользователь может увидеть все данные по записи, если он обнаружил то, что искал. Старайтесь также использовать объединения таблиц (JOIN) в запросах вместо lookup-полей на формах всюду, где это будет возможно. Хотя и возможно оптимизировать выполнение метода TDataset. Lookup, даже этот улучшенный метод не будет работать быстрее объединения таблиц (JOIN) — про работу немодифицированного метода вообще можно не упоминать.