SSRS 报告中动态 SQL 查询的替代方案答案

【问题标题】：Alternative to dynamic SQL query in SSRS reportSSRS 报告中动态 SQL 查询的替代方案
【发布时间】：2014-02-22 03:26:53
【问题描述】：

我希望在应用程序中使用 SSRS 生成报告，并且发现使用在 SSRS 报告中定义的 SQL 数据集非常严格。据我所知，我可以通过将 SQL 查询作为参数实际传递给报表并将数据集设置为使用该参数作为 SQL 查询来解决这个问题。我确实知道这种动态 SQL 通常不受欢迎，但我需要看看我的选择是什么。

这里有一些背景知识，我的理由是我有一些非常复杂的查询，并且在我的 PHP 应用程序中我有很多结构（连接、子查询等）被抽象出来，这使得制定查询和重新- 跨应用程序不同部分的可用子句。我可能可以使用函数在报表生成器中实现相同的功能（仍然需要动态 sql），但我仍然会复制我在 PHP 中已经拥有的一堆东西（请记住，特定语言无关紧要），因为我需要一些我的应用程序中那些相同的 SQL 结构。我也不想使用存储过程，根据过去的经验，我发现一旦查询变得非常复杂并且你有很多不同的可能条件，它就会变得很难看。存储过程中的动态 SQL 是调试的噩梦，而且会让您失去使用存储过程的性能优势。

所以我很好奇的是，将 SQL 字符串传递给报告而不是内联查询对性能有何影响（请记住，无论如何我都不会使用存储过程）。它会以某种方式使查询变慢，还是相当于在 PHP 中执行查询？其次，与这种做法相关的其他问题/风险是什么？如果我在传递 SQL 之前对其进行了清理，那么这样做是否会有其他重大安全风险？第三，有没有更好的替代方案？

【问题讨论】：

标签： sql-server reporting-services

【解决方案1】：

我主要将其视为问题 sql 注入。如果您可以传递查询，那么任何人都可以做到。

为什么不真正使用存储过程，它是编译好的，即使动态 sql 不是最好的，它也可能值得。

顺便问一下，您确定您的查询是如此复杂以至于应该构造它吗？不是sql本身的问题吗？

你有没有想过函数（当然是动态的）。

有很多解决方案，如果我使用 ssrs 传递我的查询的某些部分，它总是布尔值，没有 sql 注入的可能性

【讨论】：

是的，我们的想法是所有参数都应该是可清理的，它们必须是整数/日期/布尔值，这样我就可以轻松清理。然后，如果我的报告是嵌入的，我假设有一种方法可以防止直接通过 URL 运行报告，在这种情况下，没有其他人可以传递他们想要的任何 SQL，充其量他们可以尝试在参数中注入一些东西，但我会对它们进行消毒，所以它不会起作用。