#sql #reporting-services
#sql #службы отчетов
Вопрос:
У меня есть отчет о продажах SSRS, который будет запускаться пользователями много раз в день, но с разными параметрами, выбранными для отрасли и типов продуктов.
SQL-запрос использует несколько больших таблиц и является довольно сложным, поэтому его многократное выполнение приведет к снижению производительности.
Я предположил, что лучшим решением было бы создать набор данных для отчета со всеми перестановками, запустить один раз за ночь, а затем применить фильтры, когда пользователи запускают отчет.
Я попытался создать моментальный снимок в SSRS, который не учитывает параметры и, следовательно, содержит все необходимые данные, а затем отфильтровать табликс с использованием параметров, выбранных пользователями. Моментальный снимок работает нормально, но, похоже, он обновляется при запуске отчета с другими параметрами.
Моим следующим решением было бы создать таблицу для набора данных, на которую затем будет указывать отчет. Я мог бы воссоздавать таблицу каждую ночь, используя хранимую процедуру. С несколькими небольшими индексами отчет будет молниеносным.
Казалось бы, это решение работает очень хорошо, но мои знания SQL ограничены, и я не могу не думать, что это неправильное решение.
Подходит ли это? Есть ли лучшие способы? Кто-нибудь может подтвердить в любом случае?
Комментарии:
1. Как и все остальное, это зависит от ваших индивидуальных требований, но когда я сталкиваюсь с подобными отчетами, я создаю таблицу reportcache, которая содержит только необходимые данные. Обычно я добавляю это в процесс, который обновляет данные в базовых таблицах, но именно так обновляются наши данные (пакетами). Если ночь — безопасное время, то почему бы, как вы предлагаете, не обновить таблицу ‘reportcache’. Обычно у меня также есть отчет, который также вызывает обновление, таким образом, пользователи могут обновлять данные по требованию, если это абсолютно необходимо. Включите временную метку «lastupdated», которую вы также можете отобразить в отчете.
2. Спасибо, Алан, ваш вклад приветствуется.
Ответ №1:
Наборы данных SSRS имеют возможности кэширования. Я думаю, вы найдете это более полезным вместо необходимости создавать дополнительные таблицы БД и тому подобное.
Пожалуйста, смотрите здесь https://docs.microsoft.com/en-us/sql/reporting-services/report-server/cache-shared-datasets-ssrs?view=sql-server-ver15
Ответ №2:
Если скорость изменения данных достаточно низкая, а кэширование SSRS не соответствует вашим потребностям, вы можете вручную кэшировать набор записей из запроса отчета (без фильтрации) в его собственную таблицу, затем вы можете изменить отчет для запроса из этой таблицы.
Oracle и большинство реализаций хранилища данных имеют формальный механизм, специально предназначенный для этого, называемый Materialized Views, но в SQL Server такой удачи нет, хотя вы можете легко реализовать тот же шаблон самостоятельно.
У этого есть 2 существенных недостатка:
- Данные в новой таблице представляют собой моментальный снимок на момент их загрузки, поэтому этот метод лучше подходит для медленно движущихся наборов данных или отчетов, где не критично, чтобы данные были точными на 100%.
- Вам нужно будет управлять жизненным циклом данных в этой таблице, в идеале вы должны настроить задание или запланированную задачу для автоматизации этого обновления, но вы можете запустить обновление как часть логики вашего отчета (не рекомендуется, но возможно).
- Хотя это возможно, вы БЫ НЕ рассматривали возможность использования ТРИГГЕРА для обновления данных, поскольку вы уже указали, что выполнение запроса занимает некоторое время, это может оказать серьезное влияние на остальную часть вашего LOB-приложения
Если вы пойдете по этому пути, вам следует записать логику обновления в хранимую процедуру, чтобы ее можно было выполнять при необходимости и с помощью других внутренних и внешних механизмов автоматизации.
Вы также должны добавить столбец, в котором записаны дата и время выполнения набора данных, а затем заменить все ссылки в вашем отчете, которые отображают дату и время печати отчета, на время подготовки данных.
Также стоит отметить, что часто проблемы с производительностью при выполнении дорогостоящих запросов в отчетах SSRS можно преодолеть, если уменьшить функции и форматирование значений в самом SQL-запросе и перенести эту логику в определение отчета. Это касается и операций фильтрации, вы можете легко добавить дополнительные вычисляемые столбцы в определение набора данных или в поверхность разработки, и вы также можете реализовать фильтрацию непосредственно в табликсе, нет требования, чтобы каждая запись из SQL-запроса отображалась в отчете вообще, так же, как нам не нужнопоказать каждый столбец.
Иногда также могут помочь некоторые хорошо разработанные индексы, для сложных отчетов мы часто можем найти баланс между тем, что может эффективно выполнять SQL engine, и тем, что RDL может сделать для нас.
Отказ от ответственности: Это гипотетический совет, вы должны оценивать каждый отчет в каждом конкретном случае.