SSRS報告中動態SQL查詢的替代方法

Question

我正在尋找在應用程序中使用SSRS生成報告的方法，並且發現在SSRS報表中使用帶有SQL定義的數據集是非常嚴格的。 據我所知，我可以通過將SQL查詢作為參數實際傳遞給報表來解決此問題，並設置數據集以將該參數用作SQL查詢。 我知道通常不喜歡這種動態SQL，但是我需要看看我的選擇是什么。

在這里有一些背景，我的理由是我有一些非常復雜的查詢，並且在我的PHP應用程序中，我提取了許多構造（聯接，子查詢等），這使得編寫查詢和可重用子句變得更加容易遍及應用程序的不同部分。 我可能可以使用函數在報表生成器中實現相同的功能（仍然需要動態sql），但是我仍然會復制PHP中已經擁有的一堆東西（請記住，特定的語言無關緊要），因為我需要一些我的應用程序中那些相同的SQL構造。 我也不想使用存儲的proc，根據過去的經驗，我發現一旦查詢變得非常復雜並且您有許多不同的可能條件，使用它們就會很麻煩。 而且，存儲過程中的動態SQL是調試的噩夢，除了使您失去使用存儲過程的性能優勢之外。

因此，我很好奇的是，將SQL字符串傳遞到報表而不是內聯查詢有什么性能影響（請記住，無論如何我都不會使用存儲過程）。 它會以某種方式使查詢變慢，還是等同於在PHP中執行查詢？ 其次，與此做法相關的其他問題/風險是什么？ 如果我在傳遞SQL之前先對其進行了消毒，那么這樣做還會有其他主要的安全風險嗎？ 第三，是否有我沒有想到的替代方案會更好？

Answer 1

我主要將問題視為sql注入。 如果您可以通過查詢，那么任何人都可以做到。

為什么不真正使用存儲過程，它是經過編譯的，即使動態sql不是最好的，它也可能值得。

順便問一下，您確定您的查詢是如此復雜，應該構造它？ sql本身不是問題嗎？

您是否考慮過功能（當然具有動態性）。

有很多解決方案，如果我使用ssrs傳遞查詢的某些部分，則它總是布爾值，無法進行sql注入