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

 

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

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

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

288

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

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

¦ Отчет перегружает систему.

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

Типы информации в получаемых отчетах

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

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

¦ Пользователя интересуют только итоги, средние показатели и прочие агрегации, а строки с деталями ему неинтересны.

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

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

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

289

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

¦ Пользователю нужны исключения.

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

¦ Важны только лучшие (или худшие) п записей (п — хорошее круглое число).

Это действительно особый случай среди исключений, но здесь действительно сложно определить критерий исключения без первоначального изучения всех деталей из отсортированного списка. Смысл обработки такого случая — понять, что ничего волшебного в хорошем круглом п нет. Вероятно, так же удобно будет выдать отсортированный список записей, отвечающих некоторому предварительно заданному критерию исключения. Например, вы хотите наградить 10 лучших продавцов. Однако действительно ли вы хотите наградить десятого среди них, если он продал меньше, чем средний продавец за прошедший год? С другой стороны, захотели бы вы обойти одиннадцатого в списке лучших, если он продал меньше, чем десятый, на 15 долларов? Смысл в том, что, по сравнению со списком 10 лучших, по крайней мере, так же полезно выдать отсортированный список исключений — например, тех продавцов, которые превысили порог в половину миллиона долларов за квартал. Определив хороший критерий исключения, который может меняться по мере развития бизнеса, вы можете сэкономить работу сервера базы данных по поиску всех строк и выполнения полной сортировки, когда практически все данные не исключительны, и даже не имеют реального шанса достичь верхушки списка. Также вы можете получить дополнительную информацию — например, как близко одиннадцатый в списке был к десятому, и сколько продавцов превысили порог по сравнению с последним прочитанным вами отчетом.
Предыдущая << 1 .. 136 137 138 139 140 141 < 142 > 143 144 145 146 147 148 .. 161 >> Следующая
Реклама
Авторские права © 2009 AdsNet. Все права защищены.
Rambler's Top100