0

私たちは、いくつかのアプローチ間の相対的なコストを把握しようとしています。

チェックボックスで行をマークすることにより、テーブルから行を追加/保持/削除することを選択できるWebページがあります。（人々はページに新しいエントリを追加したり、既存のエントリを表示したりできます。）

Webサーバーに投稿されると、ページはエントリをループしてストアドプロシージャを呼び出し、チェックボックスの状態をパラメータの1つとして渡します。

ストアドプロシージャは現在delete、各エントリのステートメントを呼び出し、その後insertにチェックボックスがオンになっている場合はを呼び出します。これには単純さの長所があります。

そこにロジックを入れる代わりにif exists、行がすでにテーブルにあるかどうかをテストすることを考えています。

その場合、チェックボックスがマークされている場合は、そのままにしておきます。それ以外の場合は挿入します。delete逆に、行がテーブルになく、チェックボックスがオフになっている場合は、 andinsertステートメントをスキップします。これにより、などの数が最小限に抑えられdeletesますが、ロジックが増えます。

データベースの負荷に関して、一方のアプローチがもう一方のアプローチよりも一般的に好まれますか？

delete新しいレコードを追加する場合のように、実際には行に影響を与えないステートメントを呼び出すにはコストがかかりますか？これはチェックより悪いif existsですか？

テーブルは、関連するすべての列にインデックスが付けられます。600,000エントリを投稿する場合、事前に確認することには大きな利点があると思いますが、問題のページには最大100エントリが含まれます。

4

1 に答える 1

1

ここでのパフォーマンスに関する最大の問題は、すべてのエントリに対してストアドプロシージャを呼び出すことです。そのストアドプロシージャ内でDELETE/INSERT最初に使用するかチェックするかは問題ではなく、オーバーヘッドが発生します。 600Kのプロシージャ呼び出し、600Kのログに記録されたトランザクションの潜在的に大きな部分など。

テーブル値のパラメータを確認することを強くお勧めします。C＃などで600Kエントリのセットを単一のストアドプロシージャに一度渡すと、2つのセットベースの操作（擬似コード）を実行できます。

 UPDATE src SET val = t.val
   FROM dbo.tvp INNER JOIN dbo.source AS src
   ON t.key = src.key;

 INSERT src SELECT x FROM dbo.tvp AS t
   WHERE NOT EXISTS (SELECT 1 FROM src WHERE key = t.key);
于 2013-03-26T17:07:10.080 に答える