web-dev-qa-db-ja.com

変更の記録を保持するデータベースとテーブルを設計する最良の方法は？

以前の変更を追跡するために、プロジェクトに履歴機能を設定する必要があります。

今、2つのテーブルがあるとします。

NOTES TABLE (id, userid, submissionid, message)

SUBMISSIONS TABLE (id, name, userid, filepath)

例：ノートに行があり、ユーザーがメッセージを変更したい。変更前と変更後の状態を追跡したい。

アイテムが「古い」かどうかを示すこれらの各テーブルに列を設定するための最良の方法は何でしょうか。アクティブな場合は0 [〜＃〜]または[〜＃〜]削除済み/非表示の場合は1。

履歴も作成したい（AUDIT TRAIL）前の状態のidと新しい状態のidを保持するテーブル。これらのIDはどのテーブルに関連していますか？

mysqldatabase-designaudit
16
Schwarz

ご覧ください

http://www.codeproject.com/Articles/105768/Audit-Trail-Tracing-Data-Changes-in-Database

データベース設計で監査証跡を作成する方法については、非常によく読んでいます。監査証跡は、データベースの実装に必要です。システム内のデータベースユーザーのアクションを常に確認できる必要があります。

PTA（ポイントインタイム）システムで変更された行を追跡するには、PTA対象のすべてのテーブルにいくつかの標準PTA（ポイントインタイム）列を追加します。

私は以下を提案します：

DateCreated – the actual date on which the given row was inserted.
DateEffective – the date on which the given row became effective.
DateEnd – the date on which the given row ceased to be effective.
DateReplaced – the date on which the given row was replaced by another row.
OperatorCode – the unique identifier of the person (or system) that created the row.
5
Hector

データのバージョン管理機能を設計する場合、いくつかの最小限の（私は思う）要件があります。

  • データの各バージョンは自己完結型で、他のバージョンから独立している必要があります。これは、現在のバージョンと「履歴」を示すフラグやその他のインジケータがないことを意味します。また、エンティティの更新とは、新しいバージョンのみを挿入することを意味し、以前のバージョンの更新は不要です。
  • 行スパニング依存関係と呼ばれるものを避けます。これは、行の1つのフィールド（End_Date）が別の行の別のフィールド（Start_Date）と同期している必要がある場所です。これにより、データの操作がより困難になり、異常の優れた原因となります。
  • 現在のバージョンと過去のすべてのバージョンは同じテーブルにあるはずです。これにより、同じクエリを使用して、特定の日付の「現在」の過去のデータを表示したり、現在のデータを表示したりできます。
  • バージョン管理されたデータへの外部キーは、通常の（バージョン管理されていない）データと同じように機能します。
  • 設計は非常に単純であるか普遍的に理解されているため、新しい開発者の学習曲線は最小限に抑えられます。

ここ は、テックフェアで何度か行ったプレゼンテーションのスライドです。上記のすべてをどのように実行できるかについて説明します。そして here はより詳細なドキュメントです。このドキュメントについてはお詫びする必要があります-これは進行中の作業であり、すべてのセクションが完了しているわけではありません。ただし、単純なバージョン管理から完全なバイテンポラルアクセスまで、あらゆるものを実装するために必要なすべての情報が得られるはずです。

10
TommCatt