javascript - How do products like Zhihu and Fenda distinguish the identities of ordinary users and respondents in their architecture?

A WebApp has two types of users at the same time, one for asking questions and the other for answering. How can we better maintain these two identities and their respective statuses?

Option 1: The same person needs to register twice. One account is the user and the other is the respondent. To switch identities, you need to log out first and then select the identity to log in again. This seems to be clearer

Option 2: All users are ordinary users in the initial state. If they want to be promoted to become a respondent, they need to submit some kind of application. After passing the application, the respondent's mark will be added under the original user information, and the corresponding display content will also There have been changes, and it can even be said that we may not be able to return to the status of ordinary users

Option 3: The registration process for the two types of users is exactly the same. After the registration is completed, they will jump to the login page. Select an identity to log in on the login page. In fact, this is to distinguish the identity under a single account. Switching also requires logging in again

The split answer is just an example. The user behaviors of these two types of users are actually very different, and they will also be different in the presentation of some content. To give a few examples, one type is patients, one type is doctors, and one type is doctors. One is the driver, and the other is the passengers. So which solution is better to manage and maintain?

I don’t know if my description is clear. I hope someone with experience in logging in with dual-terminal or multi-identity accounts can give me some advice

Reply content:

A WebApp has two types of users at the same time, one for asking questions and the other for answering. So how can we better maintain these two identities and their respective statuses?

Option 1: The same person needs to register twice. One account is the user and the other is the respondent. To switch identities, you need to log out first and then select the identity to log in again. This seems to be clearer

Option 2: All users are ordinary users in the initial state. If they want to be promoted to become a respondent, they need to submit some kind of application. After passing the application, the respondent's mark will be added under the original user information, and the corresponding display content will also There have been changes, and it can even be said that we may not be able to return to the status of ordinary users

Option 3: The registration process for the two types of users is exactly the same. After the registration is completed, they will jump to the login page. Select an identity to log in on the login page. In fact, this is to distinguish the identity under a single account. Switching also requires logging in again

The split answer is just an example. The user behaviors of these two types of users are actually very different, and they will also be different in the presentation of some content. To give a few examples, one type is patients, one type is doctors, and one type is doctors. One is the driver, and the other is the passengers. So which solution is better to manage and maintain?

I don’t know if my description is clear. I hope someone with experience in dual-end or multi-identity account login can give me some advice

Zhihu does not require both ends. Everyone can be a questioner or an answerer. You are the answerer to other people's questions, and you can ask new questions. Registration and user management are all in one set, and roles are determined based on page logic.

Didi Taxi requires two parties, because drivers and passengers are completely two types of people and two types of behaviors, so registration and user management are two sets

Boss direct recruitment is quite special. Registration and user management are a set of processes, similar to Zhihu. But the role switching is done proactively, rather than the application automatically selecting it for you based on logic. After the user logs in, you will be asked to choose whether you are a recruiter or an applicant, and then enter the corresponding page. All future actions will be based on the corresponding role. Of course, you can also actively switch roles during use

The plan I took

Related to database design:
All role user information is stored in a basic information table, and then each role has a corresponding information appearance
For example, the basic information table stores user name, nickname, password, mobile phone, email, appearance: ordinary member Information table, merchant information table, etc.

Business process related:

• When registering, you can choose to register basic information first, and then guide users to choose to complete their appearance information

• Login is all unified login, which is convenient for expansion and unified user single sign-in service

• Share a user information, security settings and other background similar to "My Taobao"

• Specific business processing is independently developed according to the role of the backend