問題タブ [audit-trail]

監査テーブルを使用して、「2011-01-01 08:00:00.000」で実行された単一の破壊的な SQL ステートメントを記録するものを見つけています。スクリプトが実行されたこの日に、各 MyTable レコードが 1 回だけ更新されたと想定できます。この SQL はおそらくユーザーによって実行されたものであり、取得できません。MyTable が変更されるたびに、新しい値の監査証跡が AuditMyTable に保存されます。

私の元のテーブルスキーマ:

MyTable スキーマの監査証跡テーブル:

私の質問は、次のデータを取得できるように、AuditMyTable からそれ自体に対して SQL 結合を作成する方法です。

AuditMyTable.AccountId, AuditMyTable.Amount as [NullAmount], AuditMyTablePrevious.Amount as [PreviousNotNullAmount]

アイデア、ヒント、既存のフレームワーク（.NETに基づく）、ツール、そして優れた監査証跡を実装するための最良の方法についての経験を探しています。

私たちの典型的なアプリケーションは、派手なものではありませんASP.NET MVC 3-セキュリティレイヤー-ビジネスレイヤー-データアクセスレイヤー-データベース（SQL Server 2008）

私の唯一の要件は、それを簡単に実装してデータベースに保存する必要があるということです。

このアプリケーション用に特別に設定されたログイン資格情報を使用して SQL Server 2008 R2 データベースに接続する (asp.net) アプリケーションがあります。

アプリケーションはストアド プロシージャを介してレコードにアクセス/変更/削除します。ストアド プロシージャには、アクションを実行するユーザーのユーザー名をパラメーターとして渡します。

特定のテーブルのすべての更新と削除の監査ログを保持できる必要があります。また、ソリューションは可能な限り最小限にする必要があり、開発者の介入を必要としません。

私が見つけることができる最も簡単な方法は、「古い」データを履歴テーブル (A_History) にコピーするテーブル (A) にトリガーを置くことです。更新は簡単です。新しく挿入されたレコードのユーザー名を確認するだけです。ただし、削除の場合、ストアド プロシージャに送信されたユーザー名パラメーターにはアクセスできません。

CONTEXT_INFO() のようなものを使用せずにこれを実装する方法はありますか?これは、すべてのストアド プロシージャとすべての呼び出しに追加する必要があり、忘れられるはずです。

ユーザーがデータを投稿および編集できるテーブルがいくつかある小さな Web アプリケーションがあります。また、新しく投稿または編集されたデータをモデレートするアプリケーション管理者もいます。私がやりたいことは、各テーブルを監査し、管理者が承認した後にのみデータを表示することです。

アプリケーション フローは次のようなものです。ユーザーがテーブルに情報を入力します。管理者は通知を受け、その情報を承認または拒否します。が承認すると、情報がフロントエンドに表示されます。情報が承認されると、後で編集できます。ユーザーが情報を編集すると、管理者は再び通知され、編集された情報を承認または拒否する必要がありますが、以前に承認された情報は引き続き Web サイトで利用できる必要があります。

また、変更された情報の各バージョン (v1、v2、v3 など) を保持する必要があります。

これを機能させる最善の方法は何だと思いますか?

ありがとうございました。

重複の可能性：
Javaでテーブルの履歴を保持する

やあ、

ユーザーがその特定のテーブルに挿入、更新、および削除した場合、テーブル xyz の履歴テーブルを作成したい.古い値、新しい値、変更された日付、変更されたユーザーなどのレコードを履歴テーブルに保存したい. どんな助けでも本当に感謝します。事前に感謝します

作成中の製品には監査ログが必要です。SQL Server 2008 R2 を使用しています。LDF ファイルは、作成されたすべてのトランザクションの完全なログを保持していることを知りました*。

ApexSQL Log を見つけました。このツールは LDF ファイルを分析し、GUI を提供します。これは、何が可能かを示す素晴らしいデモンストレーションです。しかし、それは高価です。詳細: http://www.apexsql.com/sql_tools_log.aspx

LDFファイルを分析できる他のプログラムを知っていますか? それとも、監査証跡機能を提供する他の方法でしょうか? トリガーを作成できることを知っています。しかし、データベース スキームに何かを追加する必要がない場合は、むしろ追加したくありません。

※完全復旧モデルを選択した場合のみ。

ユーザーがテーブルを挿入、更新、削除した場合にテーブルの履歴を保持するために、Javaのサンプルプログラムが必要です。誰かがこれを手伝ってくれる？

前もって感謝します。

背景コンテキスト：

---

Projectというデータベーステーブルと同じスキーマのProjectHistoryというテーブルがあります。私はnhibernateを使用しているので、ProjectというドメインオブジェクトとProjectHistory （ Projectから派生した）というドメインオブジェクトもあります。

ゴール

---

私の目標は、これらのテーブル全体でデータを取得し、発生したイベントとしてそれらを元に戻し、C＃コードで最後のn回の変更の典型的な監査証跡画面を出力することです。

詳細

---

両方のテーブルには、次のフィールドとデータ型があります

• Id-（int）-プロジェクトの主キー、注：履歴テーブルにPKがありません
• LastUpdated（日時）
• 名前（varchar）
• 説明（varchar）
• タイムスタンプ（タイムスタンプ）

Projecthistoryテーブルの目標は、 Projectテーブルを更新するたびに、 ProjectHistoryテーブルに古いレコードを含む新しい行が挿入されるため、完全な監査証跡を取得できるようにすることです。

私はこのトリガーを使用してこれを達成します：

私の問題は、ユーザーが最新のn個のイベントを選択する監査履歴をまとめるためにC＃コードが必要になることです。

例：

---

イベントの例を次に示します。

1. 1月10日-プロジェクト1を作成します（まだ履歴にありません）
2. 1月11日-プロジェクト2を作成
3. 1月15日-プロジェクト2を編集します（プロジェクト2の履歴テーブルにエントリを1月11日の日付で最終更新者として配置します）
4. 1月25日-プロジェクト1を編集します（1月10日の日付が記載されたプロジェクト1の履歴テーブルにエントリを追加します）

したがって、履歴テーブルのlastupdatedフィールドで降順で並べ替えたかどうかを確認できるように、イベント4の結果が、順序が正しくないイベント3の結果の前に配置されました。

コード

---

私はそれらをまとめるために次のコードを試しましたが、以下に欠陥を説明します：

上記のコードに関する私の主な問題は次のとおりです。

1. 履歴レコードのLastUpdated時刻は、前回のプロジェクト更新のLastUpdated時刻を反映するため、履歴テーブルのそのフィールドで説明を並べ替えることができず、イベントの正しい降順を取得すると想定します。

   1. タイムスタンプフィールドを並べ替えに使用できますが（レコードが実際に入力された時刻であるため）、C＃nhibernateを使用してそのフィールドを並べ替えることはできないようです。このフィールドは単なるbinary（8）であるため、変換されます。 IComparableをサポートしないC＃のbyte[]に。

2. プロジェクトテーブルのlastUpdatedフィールドを使用できます。これは、 lastupdateフィールドで並べ替えると、最新の最近のイベントが順番に取得されるためです。プロジェクトテーブルだけをループして、プロジェクトごとに個別のクエリを実行して最新の履歴プロジェクトを取得することを考えましたが、同じプロジェクトIDに複数の変更が発生した場合はサポートされていません。問題は、正しい順序でデータを取得する方法がわからないことです。

私の主なポイントは、すでに解決しなければならないかなり一般的なことであると思うことを達成したいので、ここで基本的なパターンを見逃しているに違いないということです。

あるプロジェクトオブジェクトを別のプロジェクトオブジェクトと比較してフィールド差分を返すことができるコードはすでにありますが（これは完璧に機能します）、これらのテーブル全体でデータベースからこのデータを正しい順序で取得する方法を理解するための提案が必要です（クエリまたは事後のコードから）「最後のn個の変更」を表示し、ロジックを使用してこれらの各変更のフィールド差分を表示できます。

監査が必要なテーブルごとにトリガーと個別の履歴テーブルを使用して、データベースに単純な監査証跡を導入することを計画しています。

たとえば、StudentScore テーブルを考えてみましょう。これには、対応する親テーブル (Student & Course) にリンクする外部キー (StudentID、CourseID など) がほとんどありません。

StudentScore に監査が必要な場合は、監査テーブル StudentScoreHistory を作成する予定です -

StudentScore のいずれかの行が変更された場合、古い行を StudentScoreHistory に移動します。

設計に関する議論で提起されたポイントの 1 つは、参照整合性を維持するために、StudentHistory テーブルの StudentID と CourseID を FK にすることでした。これを支持する議論は、ほとんどの場合、ハード削除ではなくソフト (論理ブール値フラグ) 削除を行うためであり、参照整合性を維持して、監査テーブルに孤立した ID がないことを確認するのに適しています。

これは私には少し変わったデザインのようです。監査記録が親データの削除を停止してはならないという@Jonathan Leffler のコメントに同意します。代わりに、これが必要な場合は、監査テーブルではなく、メイン テーブルの外部キーを介して処理する必要があります。外部キーを監査テーブルに拡張する際に何らかの価値が失われていないことを確認するために、意見を求めたいと思います。

ここで私の質問は次のとおりです。 これらの外部キーを履歴テーブルに入れるのは良い設計ですか?

重要な議論 (ex パフォーマンス、ベスト プラクティス、設計の柔軟性など) の詳細を教えていただければ幸いです。

特定の目的と私たちの環境を探している人の利益のために：

目的：

1. 重要なデータ履歴を維持する
2. シナリオの再作成をサポートするユーザー アクティビティの監査を許可する
3. 限られた範囲でユーザー アクティビティのロールバックを許可する

環境：

• トランザクション データベース
• すべてのテーブルで監査が必要なわけではありません
• 特に静的/参照データに対して、可能な範囲で論理的な削除を使用します
• 非常にトランザクションの多いテーブルで、物理的な削除を使用するものはほとんどありません

私はオンラインでいくつかの記事を読んだほか、データベース駆動型アプリケーションの監査証跡の作成に関するStackOverflowに関するいくつかの回答を読みました。最も一般的な解決策は、問題のテーブルの監査テーブルを作成し、トリガーを使用して監査レコードを監査テーブルに挿入することです。

データが1つのテーブルに含まれている単純なエンティティに対してこれがどのように機能するかがわかります。

子を含む集約ルートはどうですか？

例：

Orderは、データベース内にそれぞれ独自のテーブルを持つ多数のOrderLineを含む集約ルートです。元のテーブルが変更されたときにトリガーを介して更新を受け取るデータベース内の監査テーブルもそれぞれにあると想定します。

ここで、注文について何かを変更したが、その注文明細には変更を加えなかったとします。その結果、tblOrdersが更新され、トリガーがtblOrdersAuditへの変更を反映した新しい監査レコードを挿入します。ただし、tblOrderLinesには変更が加えられていないため、tblOrderLinesAuditに一致する監査レコードはありません。

しばらくして、おそらくデータをロールバックするために、注文の以前の状態を確認する必要があります。監査記録をどのように照合しますか？