ここにシナリオがあります。外部キーを使用するか、トランザクション履歴情報のデータを保持しますか？
お客様に販売するeコマースウェブサイトがあります。 明らかに取引があります。 すべての販売について、販売に関する情報を記録します。 「購入」テーブルがあるようにします。 これはどのような列ですか？
1） 'customer_id'を使用して 'customer'テーブルに外部キーを設定する必要がありますか？ OR 2） 'CUSTOMER_NAME'、 'CUSTOMER_ADDRESS' としてスナップショットを保持...両方としてVARCHAR（X） OR 3）BOTH OR 4）は、複数のテーブルに '購入' テーブルを分離？ OR その他。
あなたの意見や理由をご記入ください。 歓迎
時間はあなたの問題領域の固有の概念である場合 - eコマースで、それはある - あなたも、あなたのスキーマ内のファーストクラスのデザインコンセプトとして扱う必要があります。
私が気に入っているオプションは、時間の経過とともに変更される可能性のあるテーブルに「有効期間」インジケータを付けることです。例えば、ここでは顧客テーブルがどのように見えるかです：
CUSTOMER
---------------
CustomerID pk
RecordVersion pk
Name
EmailAddress
HomeAddressID fk
HomeAddressRecordVersion fk
ValidFrom
ValidUntil
「購入」テーブルには、両方の得意先とRecordVersion列を指定することで、顧客テーブルに結合します。このようにして、顧客が注文した時点でどの電子メールアドレスを使用していたのかを確認したい場合、顧客テーブルからそのデータを取り出すことができます。
お客様が使用している他のメールアドレスは、一部の購入データで見つかるだけでなく、お客様の記録の一部であることからもわかります。
このモデルは非常に複雑になり、クエリが難しくなりますので、控えめに使用してください。しかし、特に製品、価格、割引、配送アドレスなどのために、それは非常に有用です。 eコマースソリューションでは
購入テーブルに必要な列については、要件によって大きく異なります。通常、購入コード、購入日、購入顧客を最小限のものとし、購入した品目のリスト（別表）を持っています。
あなたが言及しているオプションに関しては、ここではリレーショナルデータベースがあり、NoSQLソリューションには向かないと思います。
その場合、私はオプション（2）を破棄します。複数のレコードで顧客情報を複製する可能性があるため、リレーショナル・スキーマには適していません。同じ理由で私はオプション（3）も捨てるだろう。
オプション（1）は、リレーショナルデータベースアプローチに適しています。購入した商品はそれぞれ自分の顧客にリンクしています。これにより、特定の顧客が購入したことを容易に知ることができます。
指定した日付で顧客データを記録できるようにする必要がある場合は、常に顧客の履歴テーブルの作成を選ぶと、Customerテーブルにリンクできます。購入日を前提とすると、購入時にどの顧客データが「アクティブ」であったかを知ることができます。
オプション（4）については、私はあなたが何を意味するか分からないので、私はそれに答えることができません。
HTH
このアプローチは、スナップショットの格納に比べて優れたアプローチです。それは実際に関連するデータの時間次元を維持します。クエリーはより複雑になり、集中化された場所でそれを行う関数のライブラリを作成することを検討する必要があります。乾杯 – edster