回答。

変更ログテーブルは、SQLの本番テーブルでのデータ変更イベントを保存する通常のテーブルです：誰が、いつ、何を変更したか。これは、金融業界、eコマース、政府機関において重要です。

実装アプローチ:

1. アプリケーションまたはプロシージャを介した明示的なログ記録。
2. すべての変更を追跡するためのトリガーの使用。
3. 新しいDBMSでは、Change Data Capture (CDC)またはTemporal Tablesのようなシステムメカニズムを使用。

典型的な構成:

• audit_id (PK), TableName, OperationType (I/U/D), RecordID, OldValue, NewValue, ChangedBy, ChangeDT

コード例 (UPDATEのための監査トリガー)

CREATE TABLE ProductAudit (
  AuditID int IDENTITY(1,1) PRIMARY KEY,
  ProductID int,
  OldPrice money,
  NewPrice money,
  ChangedBy sysname,
  ChangeDT datetime,
  OperationType char(1)
);
GO
CREATE TRIGGER trg_ProductAudit
ON Products
AFTER UPDATE
AS
BEGIN
  INSERT INTO ProductAudit(ProductID, OldPrice, NewPrice, ChangedBy, ChangeDT, OperationType)
    SELECT d.ProductID, d.Price, i.Price, SYSTEM_USER, GETDATE(), 'U'
    FROM inserted i JOIN deleted d ON i.ProductID = d.ProductID
    WHERE i.Price <> d.Price;
END

落とし穴:

• 大きな監査テーブルはクエリの遅延を引き起こす可能性があります。
• 適切なパーティショニング/古いデータの削除が必要です。
• ロックと変更の重複排除に注意が必要です。

ひねりのある質問。

Q: 主要トランザクションがロールバックされた場合、logテーブルへの書き込みは自動的にキャンセルされますか？

A: トリガーがトランザクションの一部であれば、はい、ログへの挿入は主要な操作とともにロールバックされます。しかし、アプリケーションレベルや別のトランザクションでのロギングでは、一貫性がない可能性があります。

このテーマの細部を知らなかったための実際のエラーの例。

---

事例

銀行機関ではauditテーブルのクリーンアップメカニズムが実装されていませんでした。サイズは数億行を超え、長いバックアップ、スペース不足、全体のDBのパフォーマンス悪化を引き起こしました。

---

事例

開発者はトランザクション外の別接続を介して監査を行っていました。結果として、存在しないイベントに関する記録が作成されました（アプリケーションロジックのトランザクションはロールバックされましたが、ログの記録はロールバックされませんでした）。

---

事例

変更ログの設計時に、すべてのフィールドにNVARCHAR(MAX)型を導入して汎用性を持たせました。これは必要なく、ストレージとインデックス作成の負担を増加させ、データを効率的に分析できなくなりました。