0

最近、カーソルを回避する方法について読みました。さて、私の使い方が適切かどうか知りたいです。

オンラインで動作するスクリプト エンジン (ページに埋め込まれ、サーバー側) を作成しています。このスクリプト エンジンは、この製品の「上級」エンド ユーザーによって使用されます。ただし、この製品はデータベースで非常に重く機能し、スクリプト言語は C に似ていますが、PHP に似ているところまで単純化されています。データベースの場合、基本的にこのような構文が必要です。これは、エンドユーザーが SQL コードを手書きする必要なく、言語内で作成できる最も一貫性のある構文であるためです (そうするつもりなら、なぜ彼らは単にスキップできないのですか?生活をよりシンプルにするためのスクリプトエンジンがあります）。構文は次のようなものです。

declare DataSet $data("tablename","OtherID="+$oid);
//Dataset(string tablename,string where_clause_addon)
$data["field1"]="the data of field... ";
$data.Next();  
$data["field1"]="The data of the next row";
$data[10]["field1"]="The data of the 10th row";

これを内部的に制御するには、DataSet ごとにグローバル カーソルを作成し (アプリケーションで 1 つの接続のみを使用します)、グローバル カーソルが現在の行の位置を追跡できるようにします (SCROLL および UPDATE カーソルも同様です)。そうしないと、.Net の厄介な DataReader に対抗するために独自の SQL コントロールを作成する必要が生じるため、これにより私の生活ははるかに簡単になります。

このカーソルの使用法は問題ありませんか? これらのスクリプトを含むページは、世界中からアクセスできるわけではなく、クライアントのみがアクセスできることに注意してください (したがって、一度に 3 ～ 10 人のユーザーしかアクセスできない可能性があります)。

現在の変数の場所を追跡するためのより良い方法を知っている人はいますか? (これらは不明なスキーマのテーブルをアドレス指定できるため)

また、このようなカーソルを使用した同時実行に問題はありますか? (私のドキュメントによると、カーソルは接続に対してグローバルであり、各ページ要求はその場で新しい接続を作成するため、ユーザーは接続を共有していません)

4

1 に答える 1

8

"I have recently read about how cursors should be avoided."

They can't be avoided.

"I've read more that cursors shouldn't necessarily be avoided, but rather that cursors are slow and should only be used in certain circumstances."

Correct -- in certain situations.

Use SQL statements to do as much as possible. Don't invent your own SELECT processing logic by opening a cursor and doing a bunch of if-statements: use a WHERE clause. Don't invent your own GROUP-BY processing by opening a cursor and reading each row: use a GROUP BY clause. Don't invent your own join algorithm by using nested cursor loops: use a proper JOIN clause.

Don't invent your own SQL using cursors. Use SQL.

Generally, the "don't use cursors" folks are saying "Don't reinvent SQL algorithms by using a cursor". This is not a broad, vague "don't use cursors". It's very specific advice: "Learn SQL, don't work around gaps in your knowledge by writing cursor loops."

So long as you're not reinventing an existing SQL algorithm, there are many things for which you must use cursors.

Don't fetishize over "avoiding cursors". Do fetishize over doing as much in "pure SQL" as is reasonable.

Don't engage in premature optimization as you wring your hands over cursor/no-cursor programming. Simply write the best SQL you can and benchmark performance early and often.

If you can't figure out the best SQL, ask here for the best SQL -- without fetishizing over cursors.

于 2009-08-18T15:27:06.013 に答える