Альтернатива динамическому SQL-запросу в отчете SSRS

Question

Я ищу, чтобы использовать SSRS для генерации отчетов в приложении, и нахожу, что использование наборов данных с SQL, определенных в отчете SSRS, является довольно ограничительным. Насколько я могу судить, я мог обойти это, фактически передав SQL-запрос в отчет в качестве параметра и задав набор данных для использования этого параметра в качестве SQL-запроса. Я знаю, что динамический SQL такого рода обычно неодобрен, но мне нужно посмотреть, какие у меня варианты.

Некоторые из моих предположений о том, что у меня есть очень сложные запросы, и в моем приложении PHP у меня есть много конструкций (объединений, подзапросов и т. Д.), Что упрощает формулировку запросов, а также повторно используемые статьи в разных частях приложения. Я мог бы, вероятно, добиться такого же результата в построителе отчетов, используя функции (по-прежнему нужен динамический sql), но я все равно буду дублировать кучу вещей, которые у меня уже есть в PHP (помните, что конкретный язык не имеет значения), так как мне нужно из тех же SQL-конструкций в моем приложении. Я также не хочу использовать хранимые procs, из прошлого опыта я обнаружил, что им больно работать, когда запросы становятся очень сложными, и у вас есть много разных возможных условий, он становится уродливым. И динамический SQL в хранимых процедурах - это кошмар для отладки, помимо того, что вы теряете преимущества производительности при использовании хранимых процедур.

Так что мне любопытно, каковы последствия для производительности передачи строки SQL в отчет, а не для запроса встроенного (учитывая, что я не использовал бы хранимые процедуры независимо от того, что). Может ли это сделать запрос медленнее, или это будет эквивалент выполнения запроса в PHP? Во-вторых, каковы другие проблемы/риски, связанные с этой практикой? Если я буду дезинфицировать SQL до его передачи, будут ли другие серьезные угрозы безопасности для этого? В-третьих, есть ли альтернатива, о которой я не думаю, было бы лучше?

Answer 1

В основном я рассматривал бы как проблему sql-инъекции. Если вы можете передать запрос, тогда любой может это сделать.

Почему бы не использовать хранимую процедуру, она скомпилирована, и даже если динамический sql не лучший, возможно, это стоит.

Кстати, вы уверены, что ваш запрос настолько сложный, что он должен быть построен? Разве это не проблема с самими sql?

Вы задумывались над функцией (но с динамикой, конечно).

Существует много всякого решения, и если я использовал SSRS передать некоторые части моего запроса, это всегда было что-то логическое без возможности инъекции SQL