替代動態SQL查詢SSRS報告

Question

我正在尋找使用SSRS在應用程序中生成報告，並發現使用SSRS報告中定義的SQL數據集是相當嚴格的。就我所見，我可以通過將SQL查詢實際作爲參數傳遞給報表來解決該問題，並將數據集設置爲使用該參數作爲SQL查詢。我知道這種類型的動態SQL通常被忽略，但我需要看看我的選擇是什麼。

這裏有一些背景，我的推理是我有一些非常複雜的查詢，並且在我的PHP應用程序中，我有很多構造函數（連接，子查詢等）被抽象出來，使查詢更容易應用程序不同部分的可重用條款。我可能在使用函數的報表生成器中實現同樣的功能（仍然需要動態sql），但是我仍然在複製一大堆我已經在PHP中使用的東西（請記住特定的語言是不相關的），因爲我需要一些這些SQL結構在我的應用程序中。我也不想使用存儲過程，從過去的經驗來看，我發現它們是一個痛苦的工作，一旦查詢變得非常複雜，並且你有很多不同的可能條件，它變得很難看。存儲過程中的動態SQL是調試的噩夢，除了讓你失去使用存儲過程的性能好處之外。

所以我很好奇的是將SQL字符串傳遞給報告的性能影響，而不是查詢內聯（記住我不會使用存儲過程）。它會以某種方式使查詢變慢，或者它會等同於在PHP中執行查詢嗎？其次，這種做法有哪些其他問題/風險？假如我在傳遞SQL之前對SQL進行了清理，那麼這樣做是否會存在其他主要安全風險？第三，有沒有另外一種我沒有想到的會更好？

Answer 1

我主要看到問題sql注入。如果你可以傳遞查詢，那麼任何人都可以做到。

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

順便問一下，你確定你的查詢是如此複雜，它應該被構造？這不是SQL本身的問題嗎？

你有沒有想過功能（但當然與動態）。

有一個大量的解決方案，如果我使用SSRS來傳遞我的查詢的一些地方，它總是那麼布爾沒有SQL注入的可能性