Добро пожаловать в форум, Guest  >>   Войти | Регистрация | Поиск | Правила | В избранное | Подписаться
Все форумы / Microsoft SQL Server Новый топик    Ответить
 Агрегатные для View в 3ем поколении  [new]
*Ihor*
Member

Откуда:
Сообщений: 107
Столкнулся с огромной потерей проиизводительности при работе с отчетами из View запросов.
Особенно сильно заметно при томже AVG() для поля из View которое содержит теже SUM/AVG и т.д.
Причем падение сравнимо 1500мс vs 150мс для простых таблиц размером 3т - 10т записей.

Проэкт построен таким образом, что пользователи сами строят отчеты, и давать им первые соурсы просто нереально. Потому логично был выбран вариант, отдавать им View развертки в удобоваримом варианте. Т.е. теже Users+Company+State и т.д в развернутом ввиде с нормальными именами полей [Employer name] . Потом еже таблицы с данными также превращались в View в развернутом виде.
Проблема началась когда пытался выдать пользователю таблицы с предварительными расчетами. Т.е. избавить пользователя от писания правил деления на 0 и другие выкрутасы.. потому теже Rate , и другие показатели выдавал в готовом виде по периодам.. т.е. шло уже 3-4поколение View из View
к примеру:
Contact[View] {uses+company+state+...}
Company[View] {company+state+division+department...}
Project[View] {project+state+company+...}
Certificates[View] {cetr+company[view]+project[view]+...}
т.е. человек может бтыь развертки и считать или просто делать листинг данныг в удобоваримом виде поз знания SQL просто клацая в меню. потому тотже Certificates[View] уже получился 2-3 поколения как минимум.
Чтобы посчитать теже Rateы для примеру в который берутся данные и делятся на показатель какойто и естественно нужно проверять на деление на 0 .. Я сразу заложил в View т..е появилсиь поля (COUNT(1l)/SUM(val)) as [rate] сразу вставил проверку ISNULL и другие расчеты. теперь Certificates[View] имеет вывод и агригатные колонки.

Вот тепреь к проблеме.. создавая уже новый View отчета Report1[View] в котором будет тотже AVG(Certificates.rate) мгновенно падает производительность в десятки раз. Пререпробовал тучи вариантов, и выяснил что иммено из за наложения Агрегатного на Расчетный с агригатными при ситуации View из View. для простых данных как писал выше падало с 150ms до 1500ms /

Добавить индексы в View неполучилось так, как все View содержат JOIN других таблиц, а индексация View допустима по доке только для чистых таблиц.

Я прекрасно понимаю что так делать нельзя, и для себя и своих отчетов ято могу переделать.. но ведь делается дл яПРостого пользователя. который должен знать максимум что он хочет и откуда получить. Грубо говоря перед ним выводится аля Эксель. и он тупо выбирает.. тут сумму, тут avg а тут развернутьи повернуть по кварталам.
Тепреь непонятно как представлять пользователям простые развертки с расчетами, если при лубой задаче над ними мгновенно падает производительность.
27 июн 12, 15:21    [12783328]     Ответить | Цитировать Сообщить модератору
 Re: Агрегатные для View в 3ем поколении  [new]
dmitry stakanov
Member

Откуда:
Сообщений: 241
*Ihor*,

пример приведите.
27 июн 12, 15:34    [12783449]     Ответить | Цитировать Сообщить модератору
 Re: Агрегатные для View в 3ем поколении  [new]
*Ihor*
Member

Откуда:
Сообщений: 107
dmitry stakanov,

это ведь нужен пример с данными.. ну попробую навоять генератор демки
27 июн 12, 15:42    [12783520]     Ответить | Цитировать Сообщить модератору
 Re: Агрегатные для View в 3ем поколении  [new]
Crimean
Member

Откуда:
Сообщений: 13147
а может таки в олап? дать им кубы и пусть сверлят?
а то вы напишите вы что-то достаточно вменяемое типа

Clients.* , ( select ClientId , sum( Debit ) as Debit ... ) join Clients on Clients.Id = .. ClientId

а они начнут к этому делать что-то типа

where ClientName like '%иванов%' or ( Debit + Credit / 2 ) between ( select .. ) and ( select ... )

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

а так строим кубы, с планировщика / событийно процессим это дело регулярно и инкрементально - сверлись - не хочу. а в MDX там наворотили такого, что обычные t-sql агрегаты нервно покуривают давно
27 июн 12, 15:43    [12783522]     Ответить | Цитировать Сообщить модератору
 Re: Агрегатные для View в 3ем поколении  [new]
dmitry stakanov
Member

Откуда:
Сообщений: 241
*Ihor*,
в общем, если разобрать весь этот ужас не позволяют бизнес требования или еще что-либо, то вариантов мало:

1 пробовать хранить предрассчитанные агрегаты по каждой комбинации измерений в таблицах;
2 изменить стратегию построения вью, хранить агрегаты и материализованном вью, далее использовать в конструкторе;
3 соглашусь с Crimean, выносить это все в олап – самое адекватное решение.
28 июн 12, 11:23    [12787451]     Ответить | Цитировать Сообщить модератору
Все форумы / Microsoft SQL Server Ответить