最近、以前のブログ、広告システムの歴史資料 、記事の背景を読んでいて、忘れていましたが、淘宝網のスナップショットがどのように行われているかを考えています。
2つの質問、バージョンの設計方法、履歴スナップショットと元の資料は同じIDですか？
解決策1：最初は、別のID、同じテーブルについても考えました。これは、履歴オブジェクトと現在のオブジェクトの同じスペースに相当します。つまり、エンティティは不変です。これは少し冗談です。 。注文に関連付けられている現在の外部キーコンテンツID変更のたびに変更する必要があります。マーチャントの現在の注文クエリはより面倒です。gmt_modifiedを使用して最新のものを識別する必要があります。すべての履歴テーブルには統一された属性がなく、最後の不変のみです。エンティティ。
| orderId（一意のインデックス） | producterId | lastOrderId |
短所：履歴とエンティティの相関関係が明確ではなく、論理的ではありません。
オプション2：もう1つはスペースの分離です。履歴テーブルは特別なテーブル（最新のIDを含む）であり、IDは一意のキーではありません。すべての履歴テーブルは同じエンティティIDに属します。
| orderId | producterId |
| historyId（一意のインデックス） | orderId | lastHistoryId | updateTime |
オプション2に基づいてスナップショットを設計する方がはるかに簡単です。
各注文の下に材料があり、各場所の材料（または材料のサブフィールド）には、独自の履歴データとタイムスタンプがあります。
タイムスタンプを使用してスナップショットオーダーの材料情報を照会します。
デジタル版では達成できないことを忘れないでください。ユーザーはorderIdのバージョンを記録します。注文に多くの材料（属性）がある場合は、変更するたびにバージョンを変更する必要があります。
このバージョンは、エンドとサーバー間の同期に適しており、最新のデータであるかどうかを判断し、最新でない場合はクエリを実行します。