How to implement versioning of some entity in the database?

Question

MySQL

Hello.
Let's imagine a situation - we have users who fill out a questionnaire. According to the conditions, the questionnaire cannot be edited, you can only roll out a new version of the questionnaire, and the old one must be saved for history so that site owners can always track what was indicated at which step of the questionnaire.
I myself see the following options:
1) The database has a profile table, which has a status field , where you can specify whether the profile is current, new or old. Here is the schedule:

id | field | field | status
1    --       --       old
2    --       --       actual
3    --       --       new

Here it is just clear that the first questionnaire is already outdated, the second is relevant, and the third is an application for change.
What are the advantages - everything is simple and clear.
Cons - if we add one more field, then this is still half the trouble - we simply will not have a match for this field in previous questionnaires, however, if you need to delete some field from the table, it turns out that in previous questionnaires it is also will be removed. Not exactly what we would like.
2) A structure in which there is some table containing the field names and the
profile_history value

id | field | value        |        version
1  name  Alex                    1
2   age  21                      1
3  name  Alexander               2
3  name  Alexander Great         3

Pros - here we save the whole picture, can be used for any entity in general to track previous versions, the profile table contains only the current profile
Cons - confused and also implemented poorly.
The request of experienced people to suggest which approach is the most acceptable and what are the pros and cons of these two approaches, otherwise I’m sawing a project and don’t want to lay an architectural poop in it for the future))

Answer 1

A profile is some kind of entity, and it asks to call it a document and use some kind of nosql document database.
As for your case, add the versionid in the table and stupidly copy the entire record increasing the version.
I agree it will take more space, but do not overcomplicate the scheme

Answer 2

Пользователь- его профиль с датой изменения. The current profile with the maximum date.

approves the new profile

Add a field дата одобренияand its maximum value.
Date is a natural way to sort.

Answer 3

I am not a MySQL expert, but this DBMS, like almost all modern relational DBMS, supports the JSON data type. In cases like yours, I "emulate" MongoDB in a relational DBMS by creating a table with an ID field - autoincrement and a DATA field - JSON. And already in JSON add the version field and whatever.
This will also solve the problem with the new fields of the questionnaire.
You can add JSON to an existing table, or you can write a migration utility. Both ways are relatively simple.