How to store different versions for some data in DB?

Question

MySQL

Hello!
Suppose I have a certain entity, for example, a vehicle - a car. The car has characteristics: power, torque, weight.
Suppose a user added some new car to the database, and filled in only the power - 100 hp.
After a while, another user came and decided to supplement the characteristics by indicating the torque: 200 Nm. Also, he has information that the power of this vehicle is not 100 hp, but 92 hp, he edits this information and presses the "Submit for moderation" button.
However, users continue to see the first version with a power of 100 hp. The next day, the moderator enters the admin panel and sees that a data addition has appeared for such and such a car, he looks at the changes made, clicks apply, and after that the second version becomes up-to-date, starting from this moment, site visitors see the updated version, and the previous one becomes irrelevant, while at any time the moderator can return the previous state if the data is not confirmed.
Some kind of mediawiki engine or posts in WordPress (if I'm not mistaken).
Could you tell me how to design such a database? For versions to get the separate table or to store in the same place and to change a flag? Maybe some interesting reading on this topic came across?

Answer 1

Store all entity attributes not in a table with the entity, but in a separate table, in which you additionally enter the fields: entity id, ATTR - attribute code, DATEBEG - attribute start date, DATEEND - attribute end date.
When an attribute is added, the old attribute is not removed, but its DATEEND is simply changed, and a new attribute entry with DATEEND=null is added.
Thus, you will have the entire history of attribute changes and you can easily roll back to any version of each specific attribute or all attributes of an entity.
Because attributes can be of different types, it can be implemented in two ways:
1. 1 table for attributes of one entity, which contains fields for storing attribute values ​​of all types. In this case, only the required field is filled in, the rest remain null;
2.Several tables for attributes of the same entity, one table for each attribute data type. The structure of the tables is the same (maybe except for the field name for the attribute value).
In life I saw both implementations, both work quite acceptable. Perhaps in the first option there will be a small overrun of disk space due to unused fields and indexes. The implementation is similar in both cases.