トリガーを使用して別のテーブルを更新するのが賢明ですか？

Question

を持っています Object 統合サービスから入力されたテーブル（必要に応じて変更できます）別のデータベースから。特定の時点で、別のテーブルに投稿を手動で追加する必要があります ObjectObjectGroup (ObjectId, ObjectGroupId) 必要な場合 Object.ObjectType 特定の整数値を持っています。統合サービスはそのような更新を処理しないため、擬似コードでは次のようなオブジェクトテーブルにトリガーを追加することを考えています。

if Object.ObjectType = 10
    begin
        if Object.ObjectNumber like '<string pattern>'
        begin
            insert into ObjectObjectGroup values...
        end
    end

このセットアップは賢明ですか、それともパフォーマンスの面でより良い方法がありますか？

Answer 1

主にこれから私の応答をコピー/貼り付けます 質問 StackOverFlowで

トリガーは非常に魅力的です。最初に使用を開始すると、あらゆる種類の問題に対する魔法の弾丸のように見えます。しかし、彼らは「魔法」のものを起こします。データベースが裏返しになっていないと、本当に奇妙なことが起こるように見えることがあります（他のテーブルへの挿入、入力データの変更など）。トリガーとして物事を実装する前に、スキーマの周りのAPIの使用を実施する代わりに真剣に検討します（できればデータベースでは、できない場合は外側）。

トリガーをまだ使用していることがあります

• 「date_created」と「date_last_edited」フィールドを追跡する
• 「ID」を挿入する（オラクルで、自動IDフィールドがない場合）
• 変更履歴を維持します

トリガーを使用したくないもの

• ビジネスルール/ロジック
• データベースの外側に接続するもの（Webサービスコールなど）
• アクセス制御
• トランザクションではないもの（トリガーで行うことはすべて、トランザクションでロールバックできる必要があります）

Answer 2

はい、それは賢明です。これが、実際には、テーブル上の挿入/更新/削除操作の後に必要なアクションを実行することをトリガーの目的です。

MS SQLのトリガーが各行を個別に処理しないが、現在のトランザクションのすべての行を一度に処理するという事実を考慮する必要があります。したがって、操作が一度に10行を挿入する場合、すべての行を一度に扱うためにトリガーのコードを考える必要があります。

Answer 3

トリガーは強力なツールであり、他のツールと同様に、使用するときは注意する必要があります。

1. あなたがトリガーで間違いを犯したとき、物事は劇的に間違っている可能性があり、あなたが痕跡を実行していない限り、あなたは気づかないでしょう...

2. 彼らは、DBのユーザー（現在のアプリケーション/任意の将来のアプリケーション/1つの更新を行う開発者）が気づかない/意図していないデータを「魔法のように」変更/挿入/削除します。

大きな問題は、トリガーを作成した後、他の開発者/ユーザーにとって、トリガーがそこにあり、それが何をするかは明らかではないことです。

とはいえ、それらはあなたのデータの完全性を維持し、変化の真の監査のための素晴らしいツールです。

トリガーに入れたいロジックがアプリケーションに最適かどうかを自問する必要があります。ルール？）