なぜ人々はSQLカーソルをそんなに嫌うのですか？[閉まっている]

オーバーヘッドと不便さのためにカーソルを使用しなくてもいいようにしたいのは理解できますが、ユーザーがカーソルを使用しなくて済むようにかなりの時間を費やしているところに深刻なカーソル恐怖症が起こっているようです。

たとえば、1つの質問では、カーソルで明らかに取るに足らないことを行う方法と、再帰カスタム関数を使用した共通テーブル式（CTE）再帰クエリを使用して提案された承認済みの回答を質問しましたが、これは処理できる行数を32に制限しています（SQLサーバーの再帰的な関数呼び出し制限のため）。これは、システムの寿命を延ばすための恐ろしい解決策であることに私を襲い、単純なカーソルの使用を避けるための途方もない努力は言うまでもありません。

このレベルの非常識な憎悪の理由は何ですか？いくつかの「注目の権威」はカーソルに対してファトワを発行しましたか？子供たちのモラルを破壊するカーソルの中心に、言い表せない悪が潜んでいますか？

Wikiの質問。担当者より回答に関心があります。

関連情報：

SQL Server早送りカーソル

編集：より正確にしましょう：通常のリレーショナル操作の代わりにカーソルを使用しないでください。それは非常に簡単です。私が理解していないのは、カーソルがより簡単で効率的なソリューションである場合でも、クーディーや何かがあるようなカーソルを回避するために人々が邪魔をしているということです。私を困惑させるのは不合理な憎しみであり、明白な技術的効率ではありません。

カーソルを使用した「オーバーヘッド」は、APIの一部にすぎません。カーソルは、RDBMSの一部が内部で機能する方法です。多くの場合CREATE TABLEとINSERT持ってSELECT発言をし、実装が明らかに内部のカーソルの実装です。

より高いレベルの「セットベースの演算子」を使用すると、カーソルの結果が単一の結果セットにバンドルされるため、APIのやり取りが少なくなります。

カーソルは、ファーストクラスのコレクションを提供する現代の言語よりも古いものです。古いC、COBOL、Fortranなどは、広く使用できる「コレクション」の概念がないため、一度に1行ずつ処理する必要がありました。Java、C＃、Pythonなどには、結果セットを含めるためのファーストクラスのリスト構造があります。

遅い問題

一部のサークルでは、リレーショナル結合が謎であり、人々は単純な結合ではなくネストされたカーソルを書き込みます。私はたくさんのカーソルとして書かれた、本当に壮大な入れ子のループ操作を見てきました。RDBMS最適化を無効にします。そして、本当にゆっくり走っています。

単純なSQLの書き換えにより、ネストされたカーソルループが結合に置き換えられ、単一のフラットカーソルループでプログラムを100倍の時間で実行できます。[彼らは私が最適化の神だと思った。入れ子になったループを結合で置き換えるだけでした。まだ使用されているカーソル。]

この混乱により、カーソルが起訴されることがよくあります。ただし、これはカーソルではなく、カーソルの誤用が問題です。

サイズの問題

本当に壮大な結果セット（つまり、テーブルをファイルにダンプする）の場合、カーソルは不可欠です。セットベースの操作では、非常に大きな結果セットをメモリ内の単一のコレクションとして具体化できません。

代替案

できるだけORMレイヤーを使用するようにしています。しかし、これには2つの目的があります。まず、カーソルはORMコンポーネントによって管理されます。次に、SQLはアプリケーションから構成ファイルに分離されます。カーソルが悪いということではありません。これらすべてのオープン、クローズ、フェッチをコーディングすることは、付加価値プログラミングではないということです。

カーソルは、手続き型の考え方をセットベースの環境に過度に適用します。

そして、彼らは遅いです!!!

SQLTeamから：

カーソルはSQL Server内のデータにアクセスする最も遅い方法であることに注意してください。は、一度に1つの行に本当にアクセスする必要がある場合にのみ使用してください。そのために考えられる唯一の理由は、各行でストアドプロシージャを呼び出すことです。でカーソルパフォーマンスの記事私はカーソルがあることを発見し30倍遅くセットベースの代替よりもオーバー。

上記の回答には、「カーソルはSQL Server内のデータにアクセスする最も遅い方法です...カーソルは、セットベースの代替よりも30倍以上遅い」とあります。

このステートメントは多くの状況で当てはまるかもしれませんが、包括的なステートメントとしては問題があります。たとえば、更新または削除操作を実行して、常に本番環境の読み取りを受信して​​いる大きなテーブルの多くの行に影響を与える状況で、カーソルをうまく利用しました。これらの更新を一度に1行ずつ行うストアドプロシージャを実行すると、セットベースの操作よりも高速になります。これは、セットベースの操作が読み取り操作と競合し、恐ろしいロックの問題が発生するためです（そして、運用システムが完全に停止する可能性があります）。極端な場合）。

他のデータベースアクティビティがない場合、セットベースの操作は全体的に高速です。本番システムでは、状況によって異なります。

カーソルは、SQL開発の初心者がセットベースの操作のほうが適している場所で使用する傾向があります。特に、従来のプログラミング言語を学んだ後にSQLを学ぶ場合、「これらのレコードを繰り返す」という考え方は、カーソルを不適切に使用する傾向があります。

最も深刻なSQLの本には、カーソルの使用を禁ずる章が含まれています。適切に記述されたものは、カーソルがその場所にあることを明確にしますが、セットベースの操作には使用しないでください。

カーソルが正しい選択、または少なくともAが正しい選択である状況は明らかにあります。

カーソルメソッドが使用されている場合、オプティマイザは、関係代数を使用して問題を変換できないことがよくあります。多くの場合、カーソルは問題を解決するための優れた方法ですが、SQLは宣言型言語であり、制約から統計やインデックスまで、データベースには多くの情報が含まれています。つまり、オプティマイザには、問題は、カーソルがほとんど明示的に解決策を指示することです。

Oracle PL / SQLでは、カーソルによってテーブルがロックされることはなく、一括収集/一括フェッチを使用できます。

Oracle 10では、よく使用される暗黙カーソル

  for x in (select ....) loop
    --do something 
  end loop;

暗黙的に一度に100行をフェッチします。明示的な一括収集/一括フェッチも可能です。

ただし、PL / SQLカーソルは最後の手段の1つです。セットベースのSQLの問題を解決できない場合に使用してください。

もう1つの理由は並列化です。データベースが大きなセットベースのステートメントを並列化するのは、行ごとの命令コードよりも簡単です。関数型プログラミングがますます一般的になるのと同じ理由（Haskell、F＃、Lisp、C＃LINQ、MapReduce ...）、関数型プログラミングにより並列化が容易になります。コンピューターあたりのCPUの数が増加しているため、並列化がますます問題になっています。

一般に、リレーショナルデータベースでは、カーソルを使用したコードのパフォーマンスは、セットベースの操作よりも桁違いに悪いためです。

上記の回答は、ロックの重要性を十分に強調していません。カーソルはテーブルレベルのロックになることが多いため、カーソルの大ファンではありません。

価値があるのは、カーソルがセットベースの対応を実行する「1つ」の場所が現在の合計であるということです。小さなテーブルでは、列ごとの順序で行を合計する速度はセットベースの操作に有利ですが、テーブルの行サイズが大きくなると、実行中の合計値を次のパスに単純に運ぶことができるため、カーソルが速くなります。ループ。ここで、現在までの合計を実行する場所は別の引数です...

このページの記事に同意します。

http://weblogs.sqlteam.com/jeffs/archive/2008/06/05/sql-server-cursor-removal.aspx

パフォーマンスの（非）問題以外では、カーソルの最大の失敗は、デバッグが難しいことです。特に、デバッグが比較的簡単で、言語機能がはるかに簡単である傾向があるほとんどのクライアントアプリケーションのコードと比較します。実際、SQLでカーソルを使用して行っていることはほとんどすべて、そもそもクライアントアプリで発生しているはずだと私は主張しています。

そのカーソルの例を投稿したり、質問にリンクしたりできますか？おそらく、再帰的なCTEよりも優れた方法があります。

他のコメントに加えて、カーソルを不適切に（多くの場合）使用すると、不要なページ/行ロックが発生します。

人々があなたとは異なる見方をしているという理由で人々を「狂気」と呼んだり、そうでなければ彼らのやり方を感じるのに十分な理由があるかもしれない専門家をあざけたりしようとするのではなく、おそらく2番目の段落の後にあなたの質問を終えることができます。

あなたの質問については、確かにカーソルが必要になる状況がありますが、私の経験では、開発者はカーソルを実際よりも頻繁に「使用」する必要があると判断しています。私の意見では、誰かがカーソルを使いすぎた場合とそうでない場合のどちらかでエラーが発生する可能性は、はるかに高くなります。

基本的に同じことを行う2ブロックのコード。多分それは少し奇妙な例ですが、それは要点を証明しています。SQL Server 2005：

SELECT * INTO #temp FROM master..spt_values
DECLARE @startTime DATETIME

BEGIN TRAN 

SELECT @startTime = GETDATE()
UPDATE #temp
SET number = 0
select DATEDIFF(ms, @startTime, GETDATE())

ROLLBACK 

BEGIN TRAN 
DECLARE @name VARCHAR

DECLARE tempCursor CURSOR
    FOR SELECT name FROM #temp

OPEN tempCursor

FETCH NEXT FROM tempCursor 
INTO @name

SELECT @startTime = GETDATE()
WHILE @@FETCH_STATUS = 0
BEGIN

    UPDATE #temp SET number = 0 WHERE NAME = @name
    FETCH NEXT FROM tempCursor 
    INTO @name

END 
select DATEDIFF(ms, @startTime, GETDATE())
CLOSE tempCursor
DEALLOCATE tempCursor

ROLLBACK 
DROP TABLE #temp

カーソルが2016ミリ秒かかるのに対し、1回の更新には156ミリ秒かかります。