変更データキャプチャと変更のロギングのトリガー
トリガーによって挿入される履歴テーブルを作成します（挿入、更新、削除後）。列の20％のみが更新されるので、変更された値のみをログに記録することにしました。値が変更されない場合は、NULL値が履歴テーブルで使用されます。例えば：
履歴テーブルの列はsparseになり、すべてのデータをログに記録する通常の実装に比べて、多くのスペースを節約します（これは、私のテストとバスのケースが原因です）。
私はSQL Server 2016 SP1 standard editionがChange Data Captureをサポートしているので、それを使用することとトリガーベースのロギングの間に長所/短所/違いがあるのだろうか？
いくつかの記事（ ここ と ここ ）を確認しましたが、Change Data Captureがこれ以上何を提供できるかわかりません。
これら2つのことから選択した場合、トリガーを選択する理由は次のとおりです。
- トリガーは関連するテーブルの変更を同期的に行うことができます（レポートテーブルを更新したり、参照整合性をチェックする必要がある場合など）
- トリガーを使用すると、適切な形式でデータを保存できますが、CDCは独自のCDCスキーマに、レポートでは機能しない可能性があるテーブルにデータを格納します。
- トリガーは、更新の種類または更新のソースをチェックし、ログに記録するもののみをログに記録するロジックを持つことができます
- 一括読み込みなどの一時的なトリガーを簡単に無効にしたり、ビジネスが大きな負荷の需要に直面している場合（ブラックフライデーセールなど）
- トリガーを使用すると、いくつかの種類の履歴を1つのテーブルに入れ、他の種類の履歴を別のテーブルに入れたい場合などに、より多くのビジネスロジックを組み込むことができます。
- トリガーはストレージのオーバーヘッドを直接追加しません（CDCは行あたり少なくとも34バイトを追加します）。
@Brent Ozarはトリガーを使用する長所（優れた有効なポイントです）をリストしましたが、情報に基づいた決定を行うために、CDCの長所をいくつか挙げたいと思います。
- CDCは別のSQLジョブによるログの読み取りを介して実装されるため、トリガーはDMLトランザクションと密接に結合（または同期）しますが、CDCはそうではありません。その結果、DMLトランザクションはトリガーのパフォーマンスの影響を受けません。
- トリガーが多くのコーディング作業を必要とする可能性がある一方で、変更データのロギングを複数のテーブルに実装する場合、CDCはよりスケーラブルです。
- トリガーはDBAにとってより頭痛の種です（それを認識していない、またはトラブルシューティングの時間など）一方で、CDCはそうではありません。
- CDCは、個々のテーブルで簡単に無効にすることもできます（トリガーは、ここIMHOの利点をデモしません）。
結局のところ、トリガーとCDCコンテキストの両方で一括データ変更（更新/削除/挿入）などの境界ケースを実行して、パフォーマンスや管理の利便性などの懸念があるかどうかを確認しようと思いますなど、最後の呼び出しを行います。