私は支払情報を格納するために使用されるアプリケーションを開発中です。トランザクション監査の追加に関する提案SQL Server 2008データベースの金融システムの場合
監査対象のテーブルでフィールドが変更されると、次のものを含む監査行が書き込まれます。1テーブル名、フィールド名、古い値、新しい値、および次の値を含む監査行を作成します。タイムスタンプ。 1つの挿入は、更新される行ごとに変更されるフィールドごとに行われます。
私はSQL Serverでトリガを避けることができます。なぜなら、ドキュメント化が難しくトラブルシューティングが難しくなるためですが、これはトリガの良いユースケースですか？
現在、アプリケーションは、それ自身で追加する必要があるすべての監査行を決定し、数十万行の監査行INSERT文をサーバーに送信します。これは本当に遅く、私たちのためには維持できません。
エンタープライズエディションを実行している場合はChange Data Captureをご覧ください。これは、トリガーやカスタム・ユーザー/タイムスタンプ・ロギングに関連するオーバーヘッドなしで、探しているDML監査証跡を提供します。
私は、同じスキーマ（マイナス主キー）と、（例えばユーザのためのUSERS_AUDITがあった）監査の下、各テーブルには、それが自身の監査テーブルの持っていた金融システムに取り組んでプラスしている：
チャー（ 1）列は（（ 'I' =インサート=削除、 'U' =更新、 'D'）GETDATE()
VARCHARのデフォルト値
datetime列を変更の種類を示すために255）欄にユーザwhを示すO変化（USER_ID()をデフォルト）
したこれらのテーブルは常に監査下の表にトリガーによって（追加のみ）に挿入しました。これにより、より多くの監査テーブルを管理しなければならず、挿入回数が少なくて済み、パフォーマンスが向上します。
以前はSPROCSで監査ロジックを実装しましたが、同じ考え方がTriggersで実行されています。
ワーキングテーブル：（ID、フィールド1、フィールド2、フィールド3、...フィールド-N）
履歴表：（ユーザーID、日付/時間、アクション（CUD）、ID、フィールド1、フィールド2、フィールド3、 ... field-n）
これにより、データの履歴がどのように変更されたかを簡単に照会することができます。
テーブルの行が変更されるたびに、履歴が履歴テーブルに作成されます。
私たちのテーブルの中には、100以上のフィールドがあるため、100以上のインサートは負荷が強すぎますし、データに何が起こったかを素早く確認する意味がありません。
まず、インサートをしているときは、これらのバルクインサートですか？ INSERTはStoredProc TSqlに基づいたトランザクションベースで行われます。接続プールはどのように見えますか？彼らは接続を開いたり閉じたりしていますか？また、トリガと制約だけでなく、インデックス作成することができますsomethings ..あなたのDBAと話して..？ – MethodMan
Event Sourcingに関する調査をお試しください。あなたにぴったりのようなサウンドです（すべてのオブジェクトは、発生したイベントから構築されます。イベントはDBに格納され、オブジェクト自体ではなく、100％のトレーサビリティを提供します）。 – driis
http://dba.stackexchange.com/のその他の質問 –