Recently, I was reading my previous blog, the historical materials under the advertising system, the background of the article, and I forgot, but I think of how a Taobao snapshot is done.
Two questions, how to design the version, is the historical snapshot and the original material the same id?
Solution 1: At the beginning, I also thought about a different id, the same table. It is equivalent to the same space of the historical object and the current object, that is, the entity is immutable. This is a bit of a joke. The current foreign key content id associated with an order It needs to change after each change. A merchant’s current order query is more troublesome. It is necessary to identify the latest through gmt_modified. All history tables have no unified attribution, only the last immutable entity.
| orderId (unique index) | producterId | lastOrderId |
Disadvantages: The correlation between history and entities is not clear. Not logical.
Option 2: The other is space separation. The history table is a special table (including the latest id), and id is not a unique key. All history tables belong to the same entity id.
| orderId | producterId |
| historyId (unique index) | orderId | lastHistoryId | updateTime |
Designing a snapshot based on option 2 is much simpler.
There are materials under each order, and the materials (or subfields of materials) at each location have their own historical data, plus a timestamp.
Query the material information of the snapshot order through the timestamp.
Remember that it is impossible to achieve through the digital version. The user records a version of the orderId. If the order has many materials (attributes), the version must be changed every time it changes.
The version is suitable for synchronization between the end and the server, to determine whether you are the latest data, if it is not the latest, then query it.