これを行う1つの方法は次のとおりです。
基本的に、既存のデータを変更または削除することはありません。新しいバージョンを作成して「変更」します。 DELETEDフラグを設定して「削除」します。
例：
- 商品の価格が変更された場合、古い注文が古いPRODUCT_VERSIONと古い価格に接続されたまま、新しい行がPRODUCT_VERSIONに挿入されます。
- 購入者が住所を変更すると、CUSTOMER_VERSIONに新しい行を挿入し、古い注文を古いバージョンにリンクしたまま、新しい注文をそれにリンクするだけです。
- 製品が削除されても、実際には削除されません。PRODUCT.DELETEDフラグを設定するだけなので、その製品に対して過去に行われたすべての注文がデータベースに残ります。
- 顧客が削除された場合（たとえば、顧客が登録解除を要求したため）、CUSTOMER.DELETEDフラグを設定します。
警告：
- 製品名を一意にする必要がある場合、上記のモデルで宣言的に強制することはできません。 NAMEをPRODUCT_VERSIONからPRODUCTに「プロモート」するか、そこでキーにして製品名を「進化」させる機能を放棄するか、最新のPRODUCT_VERのみに一意性を適用する必要があります（おそらくトリガーを介して）。
- お客様のプライバシーに潜在的な問題があります。顧客がシステムから削除された場合、データベースからそのデータを物理的に削除することが望ましい場合があり、CUSTOMER.DELETEDを設定するだけではそれは行われません。それが懸念される場合は、すべての顧客のバージョンでプライバシーに配慮したデータを空白にするか、既存の注文を実際の顧客から切断して特別な「匿名」の顧客に再接続してから、すべての顧客のバージョンを物理的に削除します。
このモデルは、多くの識別関係を使用します。これは「太い」外部キーにつながり、MySQLは最先端のインデックス圧縮をサポートしていないため（たとえば、Oracleとは異なり）、ストレージの問題になる可能性がありますが、一方でInnoDB常に データをクラスター化する PKとこのクラスタリングは、パフォーマンスに役立つ可能性があります。また、JOINはそれほど必要ではありません。
非識別関係と代理キーを持つ同等のモデルは、次のようになります。
