Generally, do backend administrator users and member users need to be separated?

For example, do the background administrator users and member users need to be separated and divided into two user tables, one member User table and one administrator user table? Can I use only one table, which of the following is better? Do the background administrator users and member users need to be separated and divided into two user tables, one member User table and one administrator user table? Can I use only one table, which is better?

Reply content:

For example, do the background administrator users and member users need to be separated and divided into two user tables, one member User table and one administrator user table? Can I use only one table? Which is better?

Thank you!

In my career, almost all front-end and back-end management members are separated, most of which are Internet products. I think I can summarize the following reasons:

1. Business Requirements: Generally, the management backend is used inside the company and does not involve third-party users. If a third-party distributor or agent is used, a special user backend is developed.

2. Security requirements: Security has reached a consensus in the industry that there is no absolute security, so we should consider the problem as much as possible to increase the difficulty of being hacked, the first layer is to hide the management background (restrict IP addresses, do not use common domain names, directories, etc.). Even if the second layer is discovered, try not to use weak passwords and add verification codes to prevent brute-force cracking, in addition, other problems may also require separate deployment. If you are independent, it is easier to expand to meet more requirements.

This is a common question and a good question.

There is no rule for technical decision-making. In fact, both of these practices exist, and there are also many outstanding application instances.

A system always needs to be addressedVerifyAndAuthenticationThat is, the question "are you claiming this person" and "Can this person do this.

From this point of view, the Division based on the user's identity to determine the user's permission range is just one of the feasible methods to achieve the purpose of "authentication", and there is no mystery.

The Administrator/User table sharding is a very crude means of dividing user identities. It has the following features:

• There is an insurmountable gap between the two, and it is almost impossible to switch identities.

• There is almost no association between the two actions.

• You don't even need a set of interfaces.

• [Important] The above features will not change once determined.

If your requirements meet the preceding requirements, you can split the table. Otherwise, the score is not counted.

However, it must be pointed out that table sharding can achieve permission control, regardless of the table. Therefore, for the sake of flexibility, it is generally a good choice regardless of the table, especially for newly written programs (requirements may change frequently.

The upstairs are all wonderful.
I am talking about my views from the data perspective.

During development, this often happens. A table is created to store data A. The subsequent development defines the data structure according to the requirements, then I found that there are several fields different from this table, and then I added several fields to add data B to this table.

In this way, everything will eventually be messed up.

Therefore, in my opinion, a table only stores one data to maintain consistency and reduce the chance of making mistakes later. Men can only enter the men's restroom.

If the authentication method is the same, it is convenient to store a table.
If the authentication methods are different, it is better to store the two tables.

The Administrator and the member account should be stored separately. The Administrator should use an ordinary member account to operate the functions of the ordinary account. Otherwise, the system will use the default rules when processing permissions, for example, the Administrator overwrites all permissions of members by default, but the actual requirement may not be as follows:

The answer to this question is: view the requirements and analyze the specific questions.

There are several superficial levels of permission:
1-registered users have only two identities: normal users and administrators. They do not have more detailed permission management.
2-permission management is required for at least one type of registered users: logically speaking, since permission management is required, it is easier to develop and maintain the unified logic.
3-permission management for different user types is different: you can skip the rules, but if the table sharding can greatly reduce the complexity of the system, the score is. For example, the permission is usually determined by TrueFalse, but the project may require the user to manage according to the vip level, the maximum upload Level 1 is 10 photos, and the maximum upload Level 2 is 50 photos. This is a non-TrueFalse decision, it may be difficult to put them together. You can consider Table sharding.

Of course, from another perspective, developers say that I have to score (or I don't know), but I can fulfill the requirements, and I will be happy to do it again. How can you get it?

One sentence, depending on the individual or needs
If administrators and members share the same authentication method, they can be put together. If they are different, it is best to share them with others.
From a personal perspective, I generally do not write user presentation and Management pages together to avoid verification.