1

私の質問は主に「パフォーマンスに最適なもの」に関係していますが、「哲学的に」話すこともできます（違いがある場合）...すぐに飛び込みましょう.

[TableA].[ColumnB] には、[TableC].[ColumnD] に存在する必要がある値が格納されます。すぐに、外部キーに関する回答はありません。何らかの理由で、この環境では「許可されていない」と想定してください。

しかし、「状況 x、y、z」により、[TableA].[ColumnB] は [TableC].[ColumnD] に存在しない値を取得することがあります。コードを「シリアル化された blob」として実行すると、データのメモリ内表現であり、[ColumnB] の値は、他のプロセスによって [TableC].[ColumnD] から削除される前に入力されます。とにかく、これは例のためなので、「なぜこの状態が起こるのか」にとらわれずに、それが起こることを受け入れてください.

問題を「修正」するには、どの方法がこれら 2 つの方法の中で最も優れているか: 1. [TableA] で on-INSERT を起動するトリガーを作成し、[ColumnB] を本来あるべき値に更新します"悪い値から良い値へ)。または、2. スケジュールされたジョブを毎時/分/更新クエリを実行するものは何でも実行して、考えられるすべての「悪い」値を対応する「良い」値に変更します。

より一般的に言えば、どちらがパフォーマンスに優れているか、および/またはベストプラクティスは何ですか: トリガー、または定期的なスケジュールされたジョブ? コンテキストでは、[TableA] が通常数十万行のオーダーであり、一度に 10 ～ 100 レコードが挿入され、数分ごとの頻度から 1 日に数回の頻度であるとします。

4

4 に答える 4

9

挿入時。

トリガーを実行することは、コールバックのようなものです。トリガーはより論理的に健全であり、すべてのクエリに遅延を分散させます。継続的なチェック (ポーリングまたは cron ジョブと呼ばれる) を行うと、時折、より深刻な遅延の瞬間が発生します。ほとんどすべての場合、一見ランダムな間隔で 100 ミリ秒のラグを追加するよりも、すべてのクエリに 1 ミリ秒のラグを追加する方が良いため、トリガー/コールバックを使用する方が良い方法です。

于 2012-04-18T00:37:51.703 に答える
1

トリガーの使用は一般的に推奨されていませんが、負荷が軽く、あなたのケースは自然なトリガーケースのようです。同じ行に対する 2 つの操作 (挿入と更新ではなく 1 つの挿入) を避けるために、代わりにトリガーを使用することを検討してください。これは、最も単純で信頼性の高いソリューションである可能性があります (操作全体がクラッシュしない信頼できるコードをトリガーに記述している場合)。

バッチ ジョブを検討しているため、タイミングの問題は気にしません。つまり、アプリケーションでは、テーブルが 1 分または 1 時間同期していなくても問題ありません。これが、テーブルが常に同期されていることを保証するトリガー アプローチとの主な違いです。潜在的なタイミングの問題は、私を不快にさせるでしょう. プラス面として、トリガーで元の挿入操作をクラッシュさせるリスクはありません。

この方法を使用する場合は、Change Tracking 機能を検討してください。変更の追跡により、前回のチェック以降に挿入された行が示されるため、テーブル全体をスキャンして新しいレコードを探す必要はありません。または、TableA に INDENITY プライマリ キーまたは一意のキーがある場合は、変更追跡機能を使用せずに同様の設計を実装できます。

于 2012-04-18T01:15:58.367 に答える
1

トリガーは、参照整合性を維持し、サーバーがパフォーマンスを最適化できるようにするため、最高のパフォーマンスとプラクティスの両方です。

于 2012-04-18T00:36:27.850 に答える
0

使用している SQL Server のバージョンはわかりませんでしたが、2008 以降の場合は、Change Data Captureを使用して、「プライマリ」テーブルへのデータ変更を追跡できます。次に、定期的に変更テーブルに対してバッチを実行し、その小さなセットに対して必要な処理を実行できます。

于 2012-04-18T15:03:15.647 に答える