0

データを処理するときに、手続き型プログラミングが絶対に避けられない場合があります。

現在、いくつかのレガシー コードの最適化に取り組んでいます。カーソル、63 組のIF/ELSEステートメントとBEGIN/ENDなどを使用します。カーソルをリバース エンジニアリングして、手続き型のプロセスにしたいと考えていました。今、私はアルゴリズムの解読の最後にいて、 . . . おっと...レコードに対して行われた各選択は、先行するすべてのレコードに対するプロセスの結果に依存するため、手続き型でなければなりません。

だから今、私は引き裂かれています...手続き型コードをSQL Server処理（CLR SP、UDFなど）と混合するための他の選択肢があります。私は仕事に適したツールを使用することを強く信じているので、このために .NET CLR SP を作成することに傾倒しています。ただし、カーソルを少し単純化するだけで、カーソルを保持する方が高速で「簡単」です。

皆さんはどう思いますか？SQL Server 内から .​​NET モジュールにアクセスできるようになったので、カーソルを使用することはもはや適切でしょうか (私の意見では、最初はおかしな/回避策でした)。

4

2 に答える 2

2

少なくとも、セッションとグローバル一時テーブルとテーブル変数の両方を備えた SQL サーバーでは、サーバー側カーソルの使用を選択するシナリオは想像できません。レガシー アプリで発見したように、すべてのコードをセットベースにできるわけではありません (代替手段はありませんか?) が、手続き的にレコードを反復処理する必要がある場合でも、カーソルは利用可能な最悪の選択肢です。

たとえば、テーブル変数を使用する（そして、このアプローチは非常に大きなテーブルセットのパフォーマンスが低下し始めます）

 Declare @Pks Table (pk integer primary key not null)
 Insert @pks(pk)
 Select pkcolName from table where ... [here put logic to 
           extract id values for rows you need to iterate over

 -- then put procedural code here ...
 Declare @pk Integer
 While Exists (Select * From @pks) Begin
     Select @pk = Max(pk) From @pks -- assuming you need to work 
                             -- on pk values from highest to lowest
     // Here do work on one record at a time, using value in @pk
     Delete @pks Where pk = @pk
 End
于 2011-11-13T00:38:19.687 に答える
0

クライアント/アプリサーバーのC＃でループを実行し、必要に応じてストアドプロシージャを呼び出します。通常、C＃は開発と単体テストがはるかに高速で簡単であり、CLRを使用している場合でも、データベース内のすべてを実行するストアドプロシージャよりも高速に実行できます。

于 2011-11-13T03:45:37.580 に答える