4
CDCを使用して履歴を追跡する場合
SQL Server変更データキャプチャは、SQL Serverトランザクションログから履歴データを読み取り、特別なテーブルに保存する機能です。 特別なテーブル値関数（TVF）を使用することにより、ユーザーはこのデータをクエリすることができ、特定のテーブルのすべての変更を取得するか、特定の時間内の変更に起因するネット変更のみを取得することができます。 CDCには特定の利点があります 特定のテーブルまたは列のみを追跡するように構成できます。 モデルの変更をある程度まで処理できます。 トランザクションログを処理するため、トリガーほどパフォーマンスに大きな影響を与えません。 簡単に有効/無効にでき、追跡する必要のあるテーブルの追加の列は必要ありません。 また、いくつかの欠点もあります。 履歴データの量は非常に速くなる可能性があります。 誰が変更を行ったかを追跡することはできません（少なくとも削除はできません）。 履歴データはトランザクションログに基づいているため、追いつくのに時間がかかります。 SQL Serverエージェントに依存します。エージェントが実行されていないかクラッシュした場合、履歴は追跡されません。 私はCDCについて多くのことを読みましたが、CDCの使い方を知っていますが、それが自分にとって適切なツールかどうかはまだわかりません。 CDCが適切なツールとなるのはどのタスク/シナリオですか？（たとえば、ユーザーがデータオブジェクトを特定の時点に復元できるようにしますか？監査しますか？データの完全な履歴を表示しますか？） いつCDCを使用せず、カスタムトリガーベースのソリューションに頼るべきですか？ 運用データベースでCDCを使用し、運用アプリケーション内でCDCデータを利用しても大丈夫ですか？（例：エンドユーザーに表示する）またはこれは明らかにこの機能の誤用ですか？ CDCは監査ツールであるとよく聞きますが、SQL Server Auditの目的はそれではありませんか？両方とも同じタスクの異なるツールですか？または、CDCを他のものに使用できますか？ 私の現在のシナリオでは、将来の複数のアプリケーションの基礎となる信頼できるデータフレームワークを構築するように求められます。正確な要件はあいまいですが、1つは、データ履歴を追跡し、他のテーブルのすべての関連データとともに古いエントリを復元できる必要があることです。私は現在、CDCをオプションとして評価していますが、推奨されるユースケースが実際には見つからないため、これが進むべきかどうかは不明です。 私は特定のシナリオに対するアドバイスに感謝しますが、回答では、Change Data Captureを使用するタイミングまたは使用しないタイミングに関する一般的なアドバイスを提供する必要があります。