What is the best way to store user status update data JSON or MSQL table?

Question

MySQL

I have a need to store the user's update status, or rather, the history of its changes. How can I best implement this.
The first option is to store this data in the text field of the MSQL table as json, but there is a problem with records that can be several thousand, or even hundreds of thousands.
Now just such a system has been implemented.

And since this violates the normality of the table, there is in part a more correct version, and for the first time definitely more optimized. Create a table where data about each update of the user's status will be stored, the last entry will be the current status and have something like this structure.

the question is will it be more optimized in the long run? after all, if we have 100k users and each will have 10k records, won't MYSQL die from this stuff?

Answer 1

the question is will it be more optimized in the long run? after all, if we have 100k users and each will have 10k records, won't MYSQL die from this stuff?

This is a question not so much about how to store data correctly, but about the possibilities of MySQL.
100k * 10k = 1 billion, with this amount of data, everything depends on the level (skill) of the MySQL administrator. Purely hypothetically - it should work, in practice, when MySQL grows to a very large scale - anything can happen, incl. Keys / links, indexes, etc. may fall down, and even the best specialists from specialized companies will not always be able to help in this case.
But, we can say unequivocally that:
a) With such volumes of data and the number of users, it will be at least a very good social media. a network (promising) or a project of a similar scale and the budget will allow you to hire good specialists to maintain this kind of database
b) JSON with such volumes will "bend" much faster than the base. This is especially true for MySQL JSON, which is purely a text field (unlike PostgreSQL for example) that is NOT indexed as JSON.
PS In general, MySQL does not really like a large amount of data in one column. Unfortunately, I can’t say what exactly this is connected with, because. I didn’t study the issue in detail, but personal tests (tests conducted personally, for oneself, without any hint of their objectivity or ultimate truth) say exactly this.
PPS Try to also look in the direction of such engines, such as ARCHIVE. I personally tried such an engine only once and I can’t voice the details, but purely logically, it is just designed for such tasks, storing "archival" information.