National two big flow entrance, we do not also think of, respectively is wechat and QQ. Therefore, in order to facilitate the acquisition of users, wechat login or QQ login are connected to this type of third-party login entrance. Today to docking wechat login, QQ login and Apple login. Say to the third party user system and our system user system docking some feasible schemes.

0x01: Our user table is the same as the third party user table

General system will have its own user system, in charge of user registration, login, logout, authority and so on. For example, the user table T_user of our user system roughly contains the following fields:

Id: primary key id username: username age: user age mobile: mobile number password: login password source_from: user source auth_flag: user authentication status create_date: registration dateCopy the code

The above is the simplest of some user information, then now to docking third-party user system. For example, connect to wechat. This is the most common third-party user docking ever. In this scheme, our user table and the third-party user table are in the same table, so it is necessary to add an identifier in the user table T_user, indicating the unique bound field between our user and wechat user. Wechat OpenID is generally used, in this case, the table needs to be modified to add a wX_OpenID field

Id: primary key id username: username age: user age mobile: mobile number password: login password source_from: user source auth_flag: user authentication status wx_openid: Wechat openID create_date: registration dateCopy the code

If you want to connect WITH QQ and Apple, there are some modifications to the table:

Id: primary key id username: username age: user age mobile: mobile phone number password: login password source_from: user source auth_flag: user authentication status wx_openid: wechat openid qq_openid: Qq openid appleid: indicates the appleid create_date: indicates the registration dateCopy the code

This scheme is simple in design. As long as a third party is connected, the original user table needs to be modified. If too many third parties are connected, the user table slowly becomes bloated. On the other hand, make changes to the original user code.

0x02: One table for our users and one table for third party users

Because the first scheme needs to constantly modify users and original code logic if it connects with additional third parties, it may cause uncertainties to production. So there’s another option that you can use: one list for our users, one list for our third party users. For example, the user table t_user is designed as follows:

Id: primary key id username: username age: user age mobile: mobile number password: login password source_from: user source auth_flag: user authentication status create_date: registration dateCopy the code

• The design of the third-party user table T_third_ACount is as follows:

Third_unique_acount: indicates the unique user ID of the third party. It can be the openID of wechat, the OpenID of QQ, or the apple ID. Type: indicates the type of the third party. Bind_flag: indicates whether to bind. 1 Indicates whether to bind. 2 Indicates whether to unbind. Create_date: indicates the binding timeCopy the code

This design, later generally do not need to modify the table structure; However, when a third party user is added, it is inevitable to change the original code logic.

0x03: One table for our users, multiple tables for third party users

Based on the second scenario, the third party user table uses a Type field to represent different third party user systems, with different enumerations constantly being added to identify different third parties. So you can remove this field, and then different third parties use different tables to identify them. For example, the user table t_user is designed as follows:

Id: primary key id username: username age: user age mobile: mobile phone number password: login password source_from: user source auth_flag: user authentication status create_date: User_id: indicates the id of the user corresponding to t_user. Wx_openid: indicates the openID of wechat. Bind_flag: Create_date: indicates the binding timeCopy the code

• QQ user system table T_QQ_ACount design is roughly as follows:

User_id: indicates the id of the user corresponding to t_user. Qq_openid: indicates the openID of QQ. Bind_flag: indicates whether to bindCopy the code

• Apple user system table T_apple_ACount design is roughly as follows:

User_id: indicates the id of the user corresponding to t_user. Appleid: indicates the appleid. Bind_flag: indicates whether to bindCopy the code

These schemes, the third party user table is a bit inflated meaning, the system is connected to the number of third party user system, there are many third party user system table.

The above three schemes, who is the best, no final conclusion. I think the best solution is to meet the needs of the project and the available business scenarios according to the requirements of the project.