いくつかの点を指摘したいだけです：
コードジェネレーターを使用する すべてのテーブルを追跡する単一の手順を持つことはできません。追跡される各テーブルで、類似しているが別個のトリガーを生成する必要があります。この種のジョブは、自動コード生成に最適です。あなたの代わりに、XSLT変換を使用してXMLからコードを生成します。XMLはメタデータから自動的に生成できます。これにより、監査ロジック/構造に変更を加えたり、ターゲットテーブルを追加/変更したりするたびにトリガーを再生成することで、トリガーを簡単に維持できます。
キャパシティプランニングを検討してください 監査のために。すべての値の変更を追跡する監査テーブルは、データベース内で群を抜いて最大のテーブルになります。これには、現在のすべてのデータと現在のデータのすべての履歴が含まれます。このようなテーブルを使用すると、データベースのサイズが2〜3桁増加します（x10、x100）。そして、監査テーブルはすぐにすべてのボトルネックになります：
- すべてのDML操作には、監査テーブルのロックが必要です
- すべての管理および保守操作は、監査のためにデータベースのサイズに対応する必要があります
スキーマの変更を考慮に入れる 。 「Foo」という名前のテーブルが削除され、後で「Foo」という名前の別のテーブルが作成される場合があります。監査証跡は、2つの異なるオブジェクトを区別できる必要があります。ゆっくりと変化するディメンションアプローチを使用することをお勧めします。
効率的に削除する必要があることを考慮してください 監査記録。アプリケーションサブジェクトポリシーで指定された保存期間が期限になると、期限のある監査レコードを削除できる必要があります。今はそれほど大したことではないように思われるかもしれませんが、5年後、最初のレコードの期限が来ると、監査テーブルが9.5TBに増えたため、問題になる可能性があります。
監査を照会する必要があることを考慮してください 。監査テーブルの構造は、監査に関するクエリに効率的に応答できるように準備する必要があります。監査を照会できない場合、その監査には価値がありません。クエリは完全に要件によって駆動され、あなただけがそれらを知っていますが、ほとんどの監査レコードは、オブジェクト（「このレコードでこのレコードにどのような変更が発生したか」）ごとに時間間隔（「昨日の午後7時から午後8時の間にどのような変更が発生しましたか？」）でクエリされます。テーブル？'）または作成者（'データベースでボブはどのような変更を行いましたか？'）。