соединения необходимо включить в состав кода останова. Не следует рассчитывать исключительно на то, что соединение будет закрыто автоматически после выхода объекта соединения из области определения. Безусловно, такое закрытие действительно происходит автоматически, но автор пришел к выводу, что при этом операция закрытия выполняется менее надежно (хотя сервер так или иначе закрывает неиспользуемое соединение по тайм-ауту), кроме того, оперативная память, выделенная на клиентском и серверном компьютерах в целях поддержки соединения, освобождается не столь быстро.

Отказ от использования необычных параметров настройки соединения.

Наибольшие проблемы в связи с вводом в действие не повторяющихся при других обстоятельствах параметров настройки соединения возникают при использовании пулов соединений, но не следует забывать и о том, что в связи с переопределением свойств соединения с помощью опции SET или других аналогичных средств SQL Server повторное применение этого соединения в других операциях доступа к базе данных может стать невозможным. Что же касается пулов соединений, то необходимо учитывать их характерную особенность - отсутствие привязки к определенной системе управления базами данных (соединения с базой данных Oracle, MySQL и др. также могут объединяться в пулы), поэтому диспетчер пула соединений может не распознать, что какое-то соединение после переопределения его свойств стало отличаться от других соединений, не изменившихся со времени их открытия и включения в пул. Итак, достаточно представить себе, что задан, например, уровень изоляции транзакций, отличный от используемого по умолчанию. Это может иметь катастрофические последствия, если то же соединение будет повторно использовано в другом процессе, действующем с учетом предусмотренного по умолчанию уровня изоляции.

По возможности, применение режима работы MARS. Режим работы MARS (Multiple Active Result Sets- несколько активных результирующих наборов) - это новое средство, впервые появившееся в версии SQL Server 2005, которое позволяет выполнять одновременно в одном и том же соединении несколько операций. Для каждой операции, требующей доступа к базе данных, создается активная среда, представляющая собой копию среды, применяемой по умолчанию для соединения с базой данных, после чего такая операция выполняется относительно независимо (но в случае уничтожения соединения прекращается аварийно).

Снижение количества операций обмена данными с сервером

Производительность системы, функционирование которой основано на использовании операций доступа к данным, во многом зависит также от количества таких операций.

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

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

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

Разумеется, пи один разработчик не стал бы намеренно применять такую организацию работы приложения, при которой вместо одной операции доступа к базе данных неоправданно используется несколько (и даже очень много) таких операций. Но, к сожалению, автору слишком часто приходилось быть свидетелем того, что разработчики, чья деятельность во всем остальном не заслуживает ни малейшего упрека, создают программы, которые характеризуются именно этим недостатком. Такие люди, специализирующиеся в области создания программного обеспечения, часто не учитывают, сколько раз вызывается код, выполнение которого приводит к увеяшшьию количества операций доступа к базе данных, и по большей части даже не задумываются над этим. Поэтому рекомендуем всегда самым тщательным образом проверять работу приложения, рассматривая при этом все аспекты его функционирования.

Ниже описаны некоторые причины, по которым организация работы приложения может оказаться недостаточно рациональной.

Выборка данных с иерархической структурой

Эта проблема очень часто обнаруживается при создании кода пользовательского интерфейса, хотя может также возникнуть в связи с применением объектной модели, в которой реализована иерархия (например, если в одном объекте представлены коллекции других объектов).

Предположим, что в пользовательском интерфейсе должна быть представлена табличная форма (или другая иерархическая структура), в верхней части которой имеется шапка, а за ней следуют данные, раскрывающие содержание шапки. Иногда шапки состоят не из одного, а из нескольких уровней. Очень часто при создании подобного интерфейса применяется подход, который состоит в том, что для обработки данных на каждом уровне иерархии предусматривается отдельная функция. Кроме того, нередко можно встретить такую организацию приложения, когда применяется определенная форма рекурсивного вызова одной и той же функции для доступа по крайней мере к части иерархии. Такая функция отвечает за создание только относящегося к ней уровня вывода, поэтому получает соответствующий параметр и на его основе формирует запрос на выборку своей части данных. Получив требуемую информацию, функция создает свою часть табличной формы, а затем либо вызывает функцию формирования следующего уровня, либо возвращает управление вызывающей функции, чтобы можно было продолжить процесс построения формы.

Таким образом, при указанной организации работы приложения применяется целый ряд небольших запросов, притом что все требуемые данные можно было бы

получить с помощью всего лишь одного или двух запросов. Иначе говоря, намного более эффективным был бы проект, в котором предусмотрено получение всех необходимых данных с помощью одного или нескольких ведущих запросов, а затем передача результирующего набора (наборов) в функцию формирования пользовательского интерфейса. И на этом все взаимодействие с базой данных было бы закончено. Вызов функции создания пользовательского интерфейса мог бы осуществляться столько раз, сколько потребуется, а выборка данных свелась бы к нескольким отдельным запросам, или операциям обмена данными с сервером.

Зависимые данные

В этом сценарии количество операций обмена данными с сервером слишком велико потому, что организация приложения предусматривает использование на определенном этапе запросов, возвращающих только промежуточные данные, т.е. данные, необходимые лишь для определения того, каким должен быть следующий запрос (иными словами, результаты, полученные вначале, фактически не представляют собой конечные данные). Предположим, что в приложении должны быть созданы отчет с данными обо всех заказчиках, которые удовлетворяют определенным критериям, причем отчеты необходимо сформировать отдельно по каждому заказчику. Безусловно, можно было бы выполнить запрос, с помощью которого создается исходный список, а затем передавать в базу данных отдельные запросы, относящиеся к каждому заказчику в полученном списке.

Но этот вариант нельзя назвать очень эффективным, поэтому можно предложить некоторые другие способы организации работы данного приложения, как описано ниже.

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

Использовать хранимую процедуру или включить в свой запрос полный пакет операторов выборки данных, чтобы в нем выполнялись все необходимые запросы и происходил возврат нескольких наборов данных в одном вызове (после чего остается лишь отдельно обработать наборы данных).

Пропускная способность

Если пропускная способность сети не позволяет своевременно передавать весь объем данных, которыми обмениваются компоненты сетевых приложений, то нормальная экспл}атация приложений становится невозможной. При этом многое зависит от того, как организовано функционирование клиентской части приложения. Если пользовательский интерфейс не формируется локально, и во время того, как пользователь открывает новое окно или развертывает список, по сети каждый раз передаются мегабайты данных, то вряд можно надеяться, что будет достигнута высокая