Do you want to separate the general admin and member users?

Title, general background Admin user and member user whether to separate, divided into two user tables, a member user table, an Administrator user table, if only one table can be, which is better

Reply content:

Title, general background Admin user and member user whether to separate, divided into two user tables, a member user table, an Administrator user table, if only one table can be, which is better

Thanks for inviting!

Almost all of my career management members are separate, most of them are Internet products, I think I can summarize a few reasons why to do this:

1. Business requirements: General management background is the internal use of the company, not involving third-party users, assuming that there are third-party distributors, agents and the like will also develop a dedicated user background

2. Security requirements: Security in the industry to reach a consensus is not absolute security, then should be considered as much as possible to increase the difficulty of the black, the first layer is to hide the management background (limit IP, do not use common domain name, directory, etc.), the second layer even if found also try not to use weak password, plus verification code anti-violence crack Then there may be a need for separate deployment, and it's easier to expand some to meet more needs than other levels.

This is a common question and a good question.

Technical decisions are not fixed pattern. In fact, both of these practices exist, and there are a number of excellent application examples.

A system always needs to solve both the verification and authentication , that is, "you are not claiming this person" and "whether this person can do this thing" two questions.

From this point of view, according to the identity of the user to determine the scope of the user's permission, this is only to achieve the purpose of "authentication" one of the possible methods, and there is no mystery.

Administrator/user sub-table, which is a fairly rude dichotomy of user identities. It is characterized by:

• There is an insurmountable gap between the two, which is almost impossible to switch identities

• There is little intersection between the behaviors that can be done, and the non-black and white

• They don't even have a set of interfaces.

• The "important" features above are determined and will not be changed.

If your needs meet the above characteristics, then the sub-table is possible. Otherwise, it should not be divided.

But it must be pointed out that: the sub-table can achieve the authority control, not the table is generally able to do. So, for the sake of flexibility, it is a good choice to keep the tables, especially for newly written programs (where requirements may change frequently).

The upstairs are very wonderful.
I stand on the point of view of the data to say my opinion.

Development, often have this situation, began to build a table for the storage of data A, after the development, received requirements, defined the data structure, and then found that the table on a few fields, and then add a few fields, the data B also exists in this table.

In this way, it will eventually mess up everything.

So, my point of view, a table only saves one data, maintains consistency, and reduces the chances of subsequent mistakes. Men can only go into men's toilets.

If the authentication method is the same, I find it convenient to save a table.
If the authentication method is different, then it is better to store two tables

Administrator and member accounts should be stored separately, the administrator to do ordinary account function operation, should be used as a regular member of the account to operate, or the system is to deal with the rights to use the default rules, such as the administrator by default override all the privileges of the member, but the actual demand may not be so

This question is still the answer to the Tiger Balm: Look at the needs, specific issues specific analysis.

Permissions this thing has several superficial levels:
1-registered users only two kinds of identities: ordinary users, Administrators, no more detailed permissions management, this you do not divide the same table.
2-rights management is required for at least one type of user in a registered user: Logically speaking, since the need for permission management, it is not divided into tables, unified logic easier to develop and maintain
3-Different user types of rights management methods are not the same: can not be divided, but if the table can greatly reduce the complexity of the system, it is divided. For example, the usual permission is TrueFalse decision, but may project requires the user by VIP level management, Level 1 upload 10 photos, 2 maximum upload 50 photos This non-truefalse decision, not to put together may be very troublesome, you can consider the sub-table.

Of course, from another point of view, the developer said I will be divided (or I will not), anyway, I can achieve the requirements, and then trouble me to be happy. How can you drop it?

Or a word, to see the individual or the need
If the administrator and the membership of the same authentication method, can be put together, not the same best divided into open
For personal, I don't normally write user presentation and management pages together to avoid validation

