Информационный сайт

 

Реклама
bulletinsite.net -> Книги на сайте -> Программисту -> Тоу Д. -> "Настройка SQL. Для профессионалов" -> 138

Настройка SQL. Для профессионалов - Тоу Д.

Тоу Д. Настройка SQL. Для профессионалов — СПб.: Питер, 2004. — 333 c.
ISBN 5-94723-959-0
Скачать (прямая ссылка): nastroykasqldlyaprof2004.djvu
Предыдущая << 1 .. 132 133 134 135 136 137 < 138 > 139 140 141 142 143 144 .. 161 >> Следующая


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

SELECT ... OD.ProductJD. ...

FROM ... Order_Details OD. ...

WHERE ...

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

SELECT ... OD.ProductJD.....PL.ProductJYice

FROM ... Order_Details OD...Price List PL

WHERE ...

AND OD.ProductJD-PL.ProductJD AND PL. Current JYi ce_Fl ag-' Y'

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

281

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

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

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

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

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

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

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

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

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

10. Решения сложных проблем

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

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

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

Слепые запросы чаще всего используются, когда конечные пользователи просто проверяют тестовую систему еще до ввода ее в промышленную эксплуатацию, чем когда у них уже есть реальная работа. Слепые запросы могут обнаружиться даже в поспешно скомпилированных автоматических тестах оценки производительности, ужасающе искажая контрольные результаты. К сожалению, именно во время такого тестирования вы, вероятно, будете искать и проблемы производительности, поэтому эти слепые запросы искажают видение проблемы и оставляют плохое первое впечатление о производительности приложения.
Предыдущая << 1 .. 132 133 134 135 136 137 < 138 > 139 140 141 142 143 144 .. 161 >> Следующая
Реклама
Авторские права © 2009 AdsNet. Все права защищены.
Rambler's Top100