ストアドプロシージャで動的SQLを使用したくないのはなぜですか？

動的SQLを使用したくないと言った人がいました。具体的な例や実際の例を挙げていただけますか？個人的には、データベースに数回コーディングします。柔軟性があるので大丈夫だと思います。私の推測では、SQLインジェクションまたはパフォーマンスについてです。他に何か？

必要に応じて、動的SQLの使用に問題はありません。実際、状況によっては、それが唯一の選択肢です。入力がサニタイズされていない場合はSQLインジェクションにつながる可能性があり、頻繁に呼び出されるモジュールで動的SQLを使用するとパフォーマンスが低下する可能性があるため、これを使用しないことをお勧めします。

それ自体は具体的な例はないと思いますが、私はこう言います：最初に通常のクエリとステートメントを使用した後、現在の状態を達成するようにしてください。動的SQL文字列の実行は、それを呼び出しているモジュールへの別のユーザーセッションで行われることに注意してください。予期しないアクセス許可の問題が発生する可能性があります。

あなたがパフォーマンスを心配している場合; 試して。セキュリティが心配な場合; 入力を検証します。正しいか間違っているかはありません。それは、その時点で利用できる情報とツールに基づいて最善の判断をすることだけです。

動的SQLはツールです。そして、それはツールとして、いくつかのアプリケーションを持っています-たとえば、管理作業にとってそれは恵みです。

特に、生成されたコードのパラメーター化を管理しなかった場合は、アプリケーションが使用するSPではあまり良くありません（SQL Serverの最新バージョンは問題を軽減しましたが、まだ有効です）。

ここでは詳しく説明しませんので、動的SQLの問題に関する優れた記事、MVP Erland Sommarskogによる動的SQLの呪いと祝福をお勧めします。

これはほとんどのdbms機能と同様です。適切な状況で使用するとうまく機能し、間違った状況では十分に機能しません。

長所：いくつかのことは、それなしでは実行できません。通常、これは管理作業用であり、アプリケーションコードではないことがわかりました。一部のシステムコマンドでは、パラメーターを入力として使用できません。したがって、たとえば、データベースが不明な多くのインスタンスで、すべてのデータベースに対してsprocを介して何かを実行する必要があり、コマンドがパラメーターを受け入れない場合、通常は動的SQLによってこれを解決します。ただし、これはMSSQLよりもSybase ASEの方が重要です。

短所：すでに知っていると思うので、詳しくは説明しませんが、SQLインジェクションを正しく使用しないと、リスクが生じる可能性があります。私にとってより大きなものは、クエリはそれが何であるか、ユニークなアドホッククエリのように扱われ、コンパイルされたクエリプランの一部ではないということです。たまに実行されるものについては、大したことはありません。1分間に数百回実行され、多くの一意のSQLが存在するものの場合、多くの新しい、潜在的に不要なクエリプランが生成され、サイクルを消費し、プランキャッシュの有効時間を短縮します。

動的SQLを使用しないでください。

ストアドプロシージャでオプションのパラメーターを使用する方法に関する知識がないため、動的SQLが使用される時間の99％、残りの1％は、顧客が理解していないレポートの非常に複雑なクエリの作成に使用されますさえ。動的SQLの呪いと祝福は、なぜそれを使用するのが良い考えの例を示していませんが、SQLのセキュリティリスクは言うまでもなく、デバッグ、保守が複雑になるため、問題があることを示唆しています。インジェクション、パフォーマンスの低下はないので、キャッシュが、一時テーブルとカーソルを使用してのようにそれに付属している悪い習慣どのコースの怠惰とナイーブプログラマーは虐待するでしょう。このようにクエリを作成する柔軟性などはありません。SQLは宣言型言語であり、そのように扱う必要があります。

怠惰はすべての悪の根です。

逆説的に言えば、この回答は最も投票数の少ないものにランクインすることになります。