говорят, в 3-й ахапте будет гораздо более дружественный интерфейс. может быть.
но мне кажется, что проблема, затронутая выше, касается не только и не столько отчетов, а логики, которая эти отчеты сопровождает - а это уже глобальная проблема всей ахапты.
Реально, на проектах, систему переписывают по несколько раз. Причем, круче всего ее переписывают уже на этапах, когда начинают тестироваться отчеты и лезут системные баги.
И вот именно когда систему переписывают под отчеты, тогда и происходит оптимизация всего, что только можно.
Касательно отчетов - я думаю выскажу мнение всех программеров - что это самая слабая нынче часть системы.
Я вижу несколько выходов:
1. Самый простой - использовать внешние генераторы отчетов. Они имеют дружественный интерфейс, мощную функциональность для построения и анализа кубов. Кроме того, можно хорошо сэкономить - не приобретая функциональность по отчетам и заплатив несколько сот долларов за какой-нить Crystal или Cognos. Опять же будут сэкономлены нервы программеров, которые не будут страдать.:-))
Но мы то не ищем легких путей
Отсюда второй вариант :
2. Переписать логику отчетов. Известно что параметризованные запросы работают в 5-6 раз быстрее - это раз. Запросы типа select автоматически преобразовываются в select for update - соответственно возникают локи, которые замедляют запросы - выход - использовать динамические запросы. На самом деле очень приятная штука, если разобраться что и к чему.:-)
3. Если со всей энергией подойти к делу переписывания логики отчетов - то скорее всего, рано или поздно - Вы прийдете к выводу - что с самого начала надо было писать свой отчет с самого начала. Вот Вам и третий способ - написать свои отчеты со своей логикой и со своими запросами.
вооот...