ストアドプロシージャで動的SQLを使用したくないのはなぜですか？
動的SQLを使用したくないと言っている人を聞いたことがあります。具体的な例や実際の例を挙げていただけますか？個人的には、データベースで数回コーディングします。柔軟性があるので大丈夫だと思います。私の推測では、SQLインジェクションまたはパフォーマンスについてです。他に何か？
必要に応じて、動的SQLの使用に問題はありません。実際、状況によっては、それが唯一の選択肢です。入力がサニタイズされていない場合はSQLインジェクションにつながる可能性があり、頻繁に呼び出されるモジュールで動的SQLを使用するとパフォーマンスが低下する可能性があるため、これを使用しないことをお勧めします。
それ自体として具体的な例はないと思いますが、私はこう言います：最初に通常のクエリとステートメントを使用した後、現在の状態を達成するようにしてください。動的SQL文字列の実行は、それを呼び出しているモジュールへの別のユーザーセッションで行われることに注意してください。予期しないアクセス許可の問題が発生する可能性があります。
あなたがパフォーマンスを心配している場合;試して。セキュリティが心配な場合;入力を検証します。正しいか間違っているかはありません。それは、その時点で利用できる情報とツールに基づいて最善の判断をすることだけです。
動的SQLはツールです。そして、それはツールとして、いくつかのアプリケーションを持っています-例えば、管理作業にとってそれは恵みです。
SPは、生成されたコードのパラメーター化を管理しなかった場合は特に問題です（SQL Serverの最新バージョンでは問題が減少しましたが、まだ有効です）。
ここでは詳しく説明しませんので、動的SQLの問題に関する優れた記事をお勧めします： 動的SQLの呪いと祝福 MVP Erland Sommarskog著。
これはほとんどのdbms機能と同様です。適切な状況で使用するとうまく機能しますが、間違った状況では十分に機能しません。
長所：いくつかのことは、それなしでは実行できません。通常、これは管理作業用であり、アプリケーションコードではないことがわかりました。一部のシステムコマンドでは、パラメーターを入力として使用できません。したがって、たとえば、データベースが不明な多くのインスタンスで、すべてのデータベースに対してsprocを介して何かを実行する必要があり、コマンドがパラメーターを受け入れない場合、通常は動的SQLによってこれを解決します。ただし、これはMSSQLよりもSybase ASEの方が重要です。
短所：すでに知っていると思うので、あまり詳しくは説明しませんが、SQLインジェクションを誤って使用すると、リスクが生じる可能性があります。私にとって大きなものは、クエリはそれが何であるか、ユニークなアドホッククエリのように扱われ、コンパイルされたクエリプランの一部ではないということです。たまに実行されるものについては、大したことはありません。 1分間に数百回実行され、多くの一意のSQLが存在するものの場合、新しい、潜在的に不要なクエリプランが大量に生成され、サイクルを消費し、プランキャッシュの有効時間を短縮します。