Несколько отчетов в SSRS с использованием той же хранимой процедуры
У меня есть проект SSRS, в котором несколько отчетов используют одну и ту же хранимую процедуру. Все отчеты различны (очевидно), но источник данных тот же.
Например, один отчет представляет собой более крупный отчет о транзакционных транзакциях с 50 + полями и 20 + параметрами, один отчет представляет собой один параметр и отчет по одной странице, по существу, просто показывающий одну запись в подробном представлении. Есть несколько других отчетов, которые очень похожи на первый (табличный) отчет, но большинство параметров дефолты и скрыты, и они используют разные поля из хранимой процедуры.
Все эти отчеты используют одну и ту же хранимую процедуру (например, sp_Transaction ), которая имеет 20+ параметров и возвращает более 100 полей. Способ, которым обрабатываются аргументы в хранимой процедуре, выглядит примерно так:
- # Ужасно даже после использования IIF, чтобы избежать деления на нуль в выражении
- Сброс параметров SSRS при изменении параметра даты
- Как удалить интервал между столбцами в столбчатой диаграмме SSRS 2012
- Выражение для удаления возврата каретки в SSRS
- Обновление каскадных параметров в отчете SSRS для выбора даты
( ( tblTransaction.TransactionID = @TransactionId ) OR ( @TransactionId IS NULL AND ( @DateCreatedDaysRelative IS NULL OR (CAST(tblTransaction.Created AS DATE)) = CAST(DATEADD(DAY, @DateCreatedDaysRelative, GETDATE() ) AS DATE) ) AND ( ( @DateStartMonthsRelative IS NULL AND @DateEndMonthsRelative IS NULL ) OR ( tblTransaction.DateStart <= DATEADD(MONTH, @DateStartMonthsRelative, GETDATE() ) AND ( tblTransaction.DateEnd >= DATEADD(MONTH, @DateEndMonthsRelative, GETDATE() )) ) ) ) ) AND ( tblTransaction.Receipt = @ReceiptRequired OR @ReceiptRequired IS NULL ) AND ( @PubID = dbo.tblJournal.PubID OR @PubID IS NULL )
Я понимаю, что его легко поддерживать один код для всего отчета, но это большая хранимая процедура, которая принимает множество аргументов и возвращает много полей, а не отчет (который использует его) фактически использует все свои аргументы или поля.
Поэтому мой вопрос: «Хорошая практика заключается в том, чтобы иметь одну общую большую часть кода, где половина входов и выходов не используется (за один раз по одному отчету) или создание отдельных хранимых процедур для каждого отчета с требуемыми входами и выходами ; или что-то вроде одной хранимой процедуры, но с динамическим sql?
- Как получить данные из собственной таблицы ссылок в sql
- Результат SSRS отличается от результата SSMS тем же запросом
- Почему мои диаграммы не отображаются в SSRS 2012?
- SQL Выберите только месяц из формата YYYYMMDD int
- Как преобразовать отчет SSRS в файл .svc с помощью запланированного задания?
- Добавление функции «Предыдущий и следующий месяц» в календарь
- Форматирование ячеек матрицы SSRS
- Разрешить множественные значения в SSRS
Это не простой вопрос Да / Нет.
Вы должны учитывать множество элементов, и, как и многие другие вещи, вы не должны злоупотреблять им.
Я бы сказал, что плохие идеи:
- Всегда используйте отдельный запрос / SP
- Всегда используйте один и тот же запрос / SP
Куда поместить курсор (в основном создавая новые запросы или в основном используя тот же запрос) между этими двумя параметрами зависит от вас.
У обоих есть плюсы и минусы, которые на моей голове:
Отдельный запрос / SP
- PRO: Индивидуальные запросы для каждого отчета, которые обрабатывают только «полезные» данные
- CON: Если требуется обновление (например, изменение имени столбца или новый столбец, необходимый для примера), вам необходимо обновить x запросов вместо 1
Тот же запрос / SP
- PRO: обновление может влиять на все отчеты, поэтому у вас меньше работы
- CON: Обновление может влиять на все отчеты, поэтому вы можете иметь побочные эффекты
Это очень простая проблема «да / нет». Это ужасная, страшная идея .
Обслуживание – важная проблема, с которой вы не хотите иметь дело, тестирование каждого отчета со всеми параметрами после любых изменений будет кошмаром и отличным способом введения ошибок.
В равной степени, если не более значительная проблема, это производительность . Этот процесс не будет масштабироваться каким-либо образом. Он не сможет использовать индексы, так как есть функции в предложении where, которые необходимо оценить для каждой строки. (есть способы смягчить эту проблему, но это сделает код менее понятным)
Является ли отчет запущенным часто, он перекомпилируется для каждого исполнения? План выполнения вряд ли будет эффективным для всех параметров, но если план будет кеширован, вызов proc с разными параметрами приведет к неизвестному времени выполнения. (опять же, есть способы смягчить это, но пострадает читаемость кода)
Есть определенные причины для использования общих наборов данных и повторного использования хранимых процедур, но наличие хранимой процедуры для всех отчетов является плохой идеей.