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

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

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

これは賢明な設定ですか、それともパフォーマンスの点でより良い方法がありますか？

ほとんどの場合、この質問の回答をスタックオーバーフローにコピーして貼り付けます

トリガーは非常に魅力的な場合があります。トリガーを初めて使用すると、あらゆる種類の問題に対する魔法のように見えます。しかし、それらは「魔法」のようなことを起こします。もしデータベースを完全に知らなければ、本当に奇妙なことが起こっているように見えます（他のテーブルへの挿入、入力データの変更など）。トリガーとして実装する前に、スキーマを中心にAPIの使用を強制することを真剣に検討します（できればデータベースで、できなければ外部で）。

まだトリガーを使用するもの

• 「date_created」および「date_last_edited」フィールドの追跡
• 「ID」の挿入（Oracleでは、自動IDフィールドがない）
• 変更履歴を保持する

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

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

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

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

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

1. トリガーを間違えた場合、事態は劇的に悪化する可能性があり、トレースを実行していなければ、気付かないでしょう...

2. それらは、DBのユーザー（現在のアプリケーション/将来のアプリケーション/ 1回限りの更新を行う開発者）が認識/意図しなかったデータを「魔法のように」変更/挿入/削除します。

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

つまり、データの整合性を維持し、変更を真に監査するための優れたツールです。

トリガーに入れたいロジックがアプリケーションまたはDB内に最適であるかどうかを自問して、両側のリスクを比較検討する必要があります（新しいアプリケーションが登場し、これを強制しない場合はどうなりますか）ルール？）