カーソルは DBMS にとって「不自然」であり、パフォーマンスが低下するため、カーソルを使用するのは良くないと聞きました。
しかし、次の状況を想像してみてください。ストアド プロシージャがあり、フランスからのすべての顧客に対してこのストアド プロシージャを呼び出す必要があります (たとえば)。カーソルを使用する、すべてのものを 1 つのクエリに書き込む、クライアント側アプリケーションからすべての顧客のストアド プロシージャを呼び出すなど、いくつかのオプションがあります。
1 つのクエリですべてのものを記述すると、既存のストアド プロシージャからコード/ロジック/クエリ全体が複製される可能性が高くなります。そして、それは「臭いアプローチ」のように見えます（「リファクタリング」の本を読んだ場合）。ロジックはもはや 1 か所にカプセル化されていません。
どう思いますか？
PS。カーソルが悪い、またはそうでない理由を説明しているドキュメントへのリンクは大歓迎です。
カーソルが使用するのに適したツールである場合があります。クエリ全体を取得し、それをセットとして操作する方がよい場合もあります。
SQL には、多くのセット指向の操作が組み込まれています。たとえば、UPDATE は、テーブルの行セット全体に対して操作できます。WHERE 句がある場合、それらは更新される行です。更新では、状況依存のサブクエリと CASE 構造を使用して、一見異なる方法で異なる行を更新するという点で多くの柔軟性を提供できます。
途方もないデータ変換を単一の UPDATE として表現することは、SQL を使い始めたばかりのプログラマーにとっては困難な作業のように思えるかもしれません。カーソルを宣言し、返された行をループ処理し、各行をレコードとして扱い、一度に 1 つのレコードの処理に戻す方がはるかに簡単です。データベースへの関与が「軽い」ままである限り、それで十分かもしれません。
しかし、産業用の強力なデータベースを構築することを期待している場合は、一度に 1 行ずつではなく、一連の行の観点からデータを操作する方法を学ぶ必要があります。パフォーマンスが向上します。おそらくもっと重要なのは、基礎となるビジネス ルールと作成したコードとの関係がより明確になることです。
適切に設計されたデータベースでは、設計が不十分なデータベースよりも、一連のデータを操作する方がはるかに簡単です。データベースの設計と、同時に SQL クエリの速度に慣れようとしている場合は、メンターにデータベースの設計についてアドバイスしてもらうことをお勧めします。そうしないと、セット指向操作のパワーと単純さを習得するのに苦労するかもしれません。
また、カーソルを使用する場合もあります。
また、カーソルのパフォーマンスは RDBMS ごとに異なることに注意してください。
ただし、カーソルがSQL データベースにとって不自然であるというケースもあると思います (これについて議論する専門家もいます)。考えてみれば、カーソルはイテレータ (または、本当に厄介にしたい場合はポインター) と考えることができます。また、反復子は手続き型言語ではうまく機能しますが、SQL のような宣言型言語にはうまく適合しません。
さて、私はその考え方に賛成または反対するほどカーソルを実際に使用していません。しかし、考えてみると、カーソルを使用して単純化されたクエリを作成したとは思えません (存在しないとは言いません)。
ストア プロシージャの記述方法によっては、SQL Server を使用している場合は関数に変換できる場合があります。関数を使用すると、次の行だけで何かを実行できます。
SELECT uf_MyFunction(customer_id, customer_name, customer_address) FROM Customer
すべての顧客レコードに適用する