There are several ways:
The first, redundant fields
User table user: id name phone email....
Third-party login table login: id uid wxopenid qqopenid...
When created Give '' and then update the relevant fields when binding later.
The second type of table splitting
User table: user: id name phone email....
Third-party table: openid: id wx_openid qq_openid....
Relationship table relationship: uid oid The oid here is the third-party table
The purpose of this design is to eliminate the need for join operations, because join operations are time-consuming when there is too much data. At the code logic layer, we first obtain the oid of the relationship based on the currently logged-in uid, and then select the relevant data in the openid table.

It is not recommended to put them all on one table. . .

1. Why not use a table? There is a field in the table, similar to type, which indicates what kind of third-party login is used.

2. If you log in with two different third parties, two accounts will indeed be generated. If you want to merge these two accounts at this time, it will be more complicated and involve which data to use. Of course, you can also do this. At worst, the information will be sent to multiple accounts at the same time.

The general idea is to first have an account (the account source can be some kind of third-party login, email registration, mobile phone registration) anyway, you need to have an account, and then bind a new third-party account after logging in. Can you parameterize the SF account settings, /user...

Update, my personal understanding of maintaining multiple third-party logins in one table
Table field - oauth table
id // can be auto-incremented
type // can be wx, qq, weibo, etc.
user_id, //corresponds to user The id
data in the table, // mysql-text type, is in json format or you can use PHP's serialization format. I recommend the json format, which corresponds to different types. You can save whatever you want. For data reading and storage, it is No difference.