0

これは、カーソルを使用せずに行ごとに SQL Call Stored Procedure と同じであると言う前に、私の質問を明確にさせてください。

ストアド プロシージャには副作用があります。実際、各呼び出しの結果がその後の処理に影響するため、これらの副作用がすべてです。

次のように考えてみてください。テーブルにはルール定義が含まれており、proc はそれらのルールを文字通り RBAR として実行し、別のテーブルに変更を加えます。

これらの条件下では、セット操作がどのように可能かわかりません.CROSS APPLYはおそらく副作用のために使用できませんが、実際にはルールテーブルに結果を結合していないため、必要ありません.

ソリューションが本当に RBAR である場合でも、CURSOR を使用しないようにする必要がありますか? READ TOP 1 WHERE Key > @Key で WHILE を使用するのがより良い解決策ですか? なんで？

検索すればするほど、fast_forward read_only カーソルが最も簡単で最速のソリューションであるという結論に達しました。

4

2 に答える 2

2

カーソルは本質的に悪い

いいえ。カーソルは簡単に誤用され、手続き型のバックグラウンドを持ち、「セットベース」についても聞いたことがないため、SQL を初めて使用する人が飛びつく傾向があります。カーソルにはそれぞれの役割があります。利用可能なアプローチを評価し、カーソルが適切であると結論付けた場合は、カーソルを使用することをお勧めします。

ループを使用しWHILEて、実際にカーソルを使用しているという事実を隠すことも、お勧めしません。

最後の注意点-あなたが言及fast_forwardしread_onlyたもの-しかし、もう1つの推奨事項local-そのように、何か問題が発生した場合、カーソルが実行されているスコープを終了すると、接続の存続期間中持続するのではなく、少なくともカーソルがクリーンアップされます.

于 2013-05-21T06:26:08.880 に答える