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

Техника решения таких проблем заключается в попытке превратить запросы в реальные соединения. Когда эти повторяющиеся запросы - это простые запросы по первичному ключу, возвращающие одну строку, то преобразование в соединение очевидно. В таких случаях, как этот пример, решение сложнее. Запрос возвратил ценовую историю, отсортированную по Ef fecti ve Date, чтобы поместить текущую эффективную цену в начале списка. Эта запись о текущей эффективной цене на самом деле единственная запись, которая нужна пользователю. Чтобы объединить этот повторяющийся запрос с другим запросом, возвращающим список Product ID, вам нужно найти способ, как присоединить первую строку, возвращенную отсортированным запросом, не считывая остальные.

Есть несколько подходов, позволяющих решить задачу с таким требованием, и я опишу два из них. Каждый подход начинается с создания нового столбца, Current Pri ce Fl ag, значение которого равно Y тогда и только тогда, когда данная цена является действующей на данный момент.

Если строки никогда не создаются с будущими значениями Ef fecti ve Date, создайте триггер, который устанавливает значение флага Current Pri ce Fl ag равным N для уже устаревших цен и создает новые цены со значением Current Pri ce Fl ag равным Y.

Если иногда создаются записи для будущих значений цены, каждую ночь запускайте пакетный процесс, который ищет будущие записи эффективных цен, только что ставших текущими, и обновляет эти записи, присваивая Current Pri ce Fl ag значение Y, одновременно изменяя значение поля Current Pri ce Fl ag для только что устаревших цен на N. Этот ночной пакетный процесс будет, вероятно, дополнять обновления при помощи триггера новых записей цен, бывших текущими на время создания.

С таким правильно созданным столбцом Current Pri ce Fl ag соединение выполнить просто. Если первоначальный запрос выглядел так:

SELECT ... OD.ProductJO. ... FROM ... Order Details OD. ... WHERE ...

TO новый запрос, включающий соединение, будет таким:

SELECT ... OD.ProductJO.....PL.Prcduct Pr1ce

FROM ... Order Details OD.....Price List PL

WHERE ...

AND 00.Product ID-PL.Product ID AND PL.Current Price Flag-Y~

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

Запросы, которые возвращают слишком много данных

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

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

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

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

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

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

Объемные оперативные запросы

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

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

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

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

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

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

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