Simple thoughts on the design of a microblog database

      In the microblog system , The current user 、 Concern （ That is, fans ）、 Followers （ The object of worship ） These three roles are indispensable . The seemingly simple relationship between them , But how will the database tables be designed , But it's hard for me to figure out , In the following solutions , Which one would you choose ? Why choose this ? Is there a better solution ?

Solution 1 ：

    This is the first design I thought of , here “ Concern ” and “ Followers ” They are stored by splicing some special characters , such as A Users have only followers B、C、D、E, Then the data stored in the follower field of the database will be B;C;D;E（ For the time being, the split character is ;）.

Based on the above scheme , Let me ask you a question ： When this user's “ Concern ” or “ Followers ” In large numbers （ such as 10 Million followers ） What kind of string of characters will it be ？ And when we need to query “ Concern ” perhaps “ Followers ” Recent blog information , Will face some time sorting queries with the blog information table , Processing difficulty is a waste of performance .

Solution 2 ：

    Based on the above problems , Someone offered me an extensible solution , At the same time, it also solves the problem of massive data in a field . Decompose the list of concerns and followers in scheme 1 into two tables , as follows ：

I was surprised to see such a design , Just imagine , If I have a user corresponding to 1W Followers , Then the user will have 10000 records in the followers table , Isn't this serious data redundancy ？ This doesn't even conform to the database design specification . But it turns out , This design is very good for the expansion of large amount of data , In that case , If the relationship between users is not limited to the relationship between attention and attention , Is it necessary to add a new table ？

Solution three ：

         Words “ A long time must be divided. , Long period of division ”, Further modification of the above design , So the two tables of scheme 2 are combined into one , as follows ：

OK, This design not only solves a considerable part of data redundancy , It can also represent a variety of relationships between users , Facilitate the future expansion of the system . But the problem comes out again , Obviously, this design also has doubts about the maintenance of state , Replace multiple tables with one table , The data must have doubled , Is it not in line with the current common saying “ Dismantle the library and the table ” Our strategic approach （ It seems that such a state is generally used for “ Mark men and women ” perhaps “ Have you deleted ” And so on. , It seems that it is rarely used in this kind of occasion ）.

In the solution of the above user relationship , It can be simply summed up as one to many , For one more , Many to many relationship , So how to design , Which is better , I hope you can analyze it together ！