3

I am about to set up a new database that will need to include archiving of records that are still accessible. Records are all associated with certain projects and when the project is archived, I want the records to stay the same, a snapshot. (e.g. If a contact is associated with an archived project, and they move a year later, I want it to still pull the old address.) The archived records do not need to be updated, but they do need to be accessible.

I have an idea of how to go about this, but I am not sure if this is the best approach: Have a duplicate of each table that would "archive" everything, and then when putting an item in archive, all the FK/PK relationships would be updated, though that seems like a cumbersome process.

Another idea I had was each item (i.e. contact) would be assigned a PK and then there would be a secondary key for each item which would then be associated with each project. The main problem with this is it seems difficult if a contact updates on a live project, a lot of updates would be required.

Please let me know if you have any questions.

Thank you for the help.

4

2 に答える 2

0

あなたが探しているのは、ドメインデータと一緒に時間データを含めることです。この種のことは、実行するのが簡単な作業ではなく、それをサポートする必要のあるアプリケーションで非常に複雑になることがよくあります。

これを行うにはいくつかの方法があり、それぞれに長所と短所があります。選択する方法は、データの時間的要素をどのように処理する必要があるかによって異なります。これらのいくつかは次のとおりです。

  1. 監査証跡
    • レコードに加えられた変更を経時的に追跡し、プライマリレコードはその現在の状態を反映します
    • データの重複を最小限に抑えます
    • 探している「スナップショット」モデルに簡単に適合しない可能性があります
  2. 最新
    • エンティティの「バージョン」ごとに、作成時のタイムスタンプを持つレコードがあります
    • ある時点に簡単に戻ることができます
    • エンティティを「フォーク」するのが簡単になります
    • データ重複が最も多い

Martin Fowlerは、時間データを処理するモデルの設計に関連するいくつかの記事を書いているので、このトピックのしっかりとした基礎を築くためにそこから始めます。

于 2012-01-18T15:54:20.073 に答える
0

うーん...このようなことに出くわしたのは、データベースではなくアプリケーション層で解決するという考えだけでした。

たとえば、ruby の場合、vestal_versions または paper-trail を使用できます。

たとえば、Paper-trail は、すべてのオブジェクトのバージョンをシリアル化されたオブジェクトとして 1 つのテーブルに格納し、デルタを操作します。

于 2012-01-18T15:41:12.027 に答える