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

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

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

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

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

Пользователя интересует поднабор данных. Просто отбросьте лишнюю часть набора данных.

Решения

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

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

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

□ Выдавайте в отчете только исключения, удаляя ненужные строки.

□ Замените отчет с первыми несколькими строками на отсортированный список исключений.

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

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

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

Распараллельте обработку отчетов с высоким приоритетом, которые нужно получить срочно.

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

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

Агрегационные данные многих детальных записей

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

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

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

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

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

Промежуточные процессы обрабатывают слишком много строк

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

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

□ Исключите детализированные данные и используйте агрегированные данные. Стоит рассмотреть предьщущий раздел, чтобы узнать, как быстро получить агрегированные данные.

□ Передавайте только исключения, удаляя ненужные строки.