更新、削除、挿入のようにストアドプロシージャを作成するときに、その理由を知りたかったのです。
update TABLE_NAME set column_name = @variable_name
それは結構です。
パラメータまたは変数を渡して次のように選択できないのはなぜですか
select @column_variable from @table_variable
回避策として動的SQLを使用する必要があることは知っていますが、それが機能しない理由は何ですか?
更新、削除、挿入のようにストアドプロシージャを作成するときに、その理由を知りたかったのです。
update TABLE_NAME set column_name = @variable_name
それは結構です。
パラメータまたは変数を渡して次のように選択できないのはなぜですか
select @column_variable from @table_variable
回避策として動的SQLを使用する必要があることは知っていますが、それが機能しない理由は何ですか?
これがSQLServerに関するものである場合、このステートメントで列名とテーブル名をパラメーター化できない理由は、
select @column_variable from @table_variable
これはすでに有効なステートメントであり、別の方法で解釈される可能性があるためです。
@name
値がデータセット列として返されるスカラー変数への参照として解釈されます。
@name
テーブル変数名、つまり型の変数の名前として解釈されますtable
。
これらの各ケースで、@name
選択する実際の列またはテーブルの名前を保持するパラメーターを示すためにを使用すると、非常に混乱します。
一方、これには別の構文が考案された可能性があると思うかもしれませんが(つまり、特に名前のパラメーター化のために)、そうではありません。
私の意見(そしてそれは私の意見であることを認めなければなりません)なぜそのような構文がないのかというと、SQLにパラメータ化可能な名前を組み込むことによって、おそらく効率の悪いクエリプランナーになってしまうからです。クエリのコンパイル時に、クエリが何をどこで選択しようとしているのかわからない場合は、実際に効率的な計画を立てることができません。
もちろん、クエリプランの作成は、名前パラメータが評価されるまで延期される可能性がありますが、クエリプランが一度保存される現在とは異なり、プランナはそのようなクエリが呼び出されるたびにプランを作成する必要があります。その後、何度も使用しました。