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

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

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

NOTES TABLE (id, userid, submissionid, message)

SUBMISSIONS TABLE (id, name, userid, filepath)

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

これらの各テーブルに列を設定する最善の方法は、アイテムが「古い」かどうかを示すことです。0アクティブであればOR削除/不可視の場合は1。

また、以前の状態、新しい状態、これらのIDが関連するAUDIT TRAILテーブルを保持する履歴（）テーブルを作成したいのですが。idid

ご覧ください

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.

データのバージョニング機能を設計するとき、いくつかの最小（と思う）要件があります。

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

以下は、テクノロジーフェアで数回行ったプレゼンテーションのスライドです。上記のすべてを行う方法について説明します。そして、ここでは詳細に入る文書があります。私はドキュメントについて謝罪しなければなりません-それは進行中の作業であり、すべてのセクションが完了しているわけではありません。ただし、単純なバージョン管理から完全なバイテンポラルアクセスまで、あらゆる実装に必要なすべての情報を提供する必要があります。