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

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

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

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

Отказ от применения курсоров

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

Но применение курсоров противоречит самот- принципу организации обработки в современных СУБД, поэтому от них следует практически полностью отказаться.

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

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

столь значительную продолжительность выполнения процесса как должное). Фактически выраженное заказчиком пожелание состояло в том, чтобы был упрощен код.

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

SET UnitPrice = UnitCost * 1.1

Ho проблема cocT05uia в том, что твердая процентная ставка была неприменимой, поскольку цены на товары приходилось устанавливать с учетом округления, на основе определенного алгоритма. Основные требования к применяемому алгоритму округления приведены ниже.

Если количество центов в цене товара после применения наценки больше или равно 50, окр)тлить цену в большую сторону до 95 центов.

Если количество центов меньше 50, округлить цену в большую сторону до 49 центов.

Псевдокод реализации указанных вычислений с помощью курсора выглядит примерно так:

Declare and open the cursor Fetch the first record

Begin Loop Until the end of the result set

Multiply cost * 1.1

If result has cents of < .50

Change cents to .49 Else

Change cents to .95 Loop

Безусловно, это - чрезвычайно упрощенная версия процедуры. Фактически для ее реализации требуется приблизительно 30-40 строк программного кода. Но вместо этой процедуры была создана версия с единственным связанным подзапросом (в который был внедрен оператор CASE). В результате этого продолжительность выполнения процедуры сократилась приблизительно до 12 секунд.

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

Использование временных таблиц

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

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

Затем вступает в действие другой процесс, с помощью которого осуществляется манипулирование этими рабочими данными.

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

SELECT ProductID, FLOOR(UnitCost * 1.1) + .49 AS TempUnitPrice INTO #WorkingData FROM Products

WHERE (UnitCost * 1.1) - FLOOR(UnitCost * 1.1) < .50 INSERT INTO #WorkingData

SELECT ProductID, FLOOR(UnitCost * 1.1) + .95 AS TempUnitPrice FROM Products

WHERE (UnitCost * 1.1) - FLOOR(UnitCost * 1.1) >= .50 UPDATE p

SET p.UnitPrice = t.TempUnitPrice FROM Product p JOIN #WorkingData t

ON p.ProductID = t.ProductID

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

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

Усовершенствование компонентов программного обеспечения, которые на первый взгпяд не требуют внимания

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