Многозначные параметры SSRS - соответствующий уровень для внедрения фильтра

Question

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

SSRS будет поддерживать любой сценарий, поэтому я спрашиваю, есть ли причина, помимо очевидной, почему это должно быть сделано на одном уровне по сравнению с другим?

Для меня имеет смысл, что изменение самого запроса и обращение к СУБД с просьбой обработать фильтрацию было бы наиболее эффективным, но, возможно, я что-то упускаю из-за того, как расширение обработки данных SSRS может справиться с этим сценарием?

Answer 1

Вы правы. Для этого нужно передать параметры в ядро ​​базы данных.

Службы Reporting Services должны идеально использоваться только для отображения контента. Чем меньше данных необходимо передать обратно в веб-браузер клиента, тем быстрее будет обработан отчет.

Вы можете найти мой ответ на аналогичный пост, касающийся использования многозначных параметров.

Передача нескольких значений для одного параметра в службах Reporting Services

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

Cheers, John

Answer 2

Использование СУБД для основной фильтрации

SSRS обеспечивает фильтрацию для отображения на основе данных и / или динамического отображения. Особенно полезно для вложенных отчетов и т. Д.

Answer 3

Использование табличных UDF - хороший подход, но есть еще одна проблема - в случае, если эта функция вызывается во многих местах запроса и даже внутри внутреннего выбора, может возникнуть проблема с производительностью. Вы можете решить эту проблему, используя переменную таблицы (или временную таблицу eather):

DECLARE @Param (Value INT)
INSERT INTO @Param (Value) 
SELECT Param FROM dbo.fn_MVParam(@sParameterString,',')
...
where someColumn IN(SELECT Value FROM @Param)

, поэтому функция будет вызываться только один раз.

Во-вторых, если вы не используете хранимую процедуру, а встроенный SQL-запрос, вы можете просто включить MVP в запрос: ... где someColumn IN (@Param) ...