Shulou(Shulou.com)06/01 Report--

This article mainly explains "how to design the general rights management of the database". The content of the explanation in the article is simple and clear, and it is easy to learn and understand. let's study and learn how to design the general rights management of the database.

First, preface

Users of the rights management system should have three different uses:

A, permission to use

B. Assign permissions

C, authorized authority

This article only analyzes from the two application levels of "using authority" and "assigning authority", and does not consider "authorization authority" for the time being.

Second, preliminary analysis

Users and roles

When it comes to rights management, you should first think of, of course, to design a user table, a permission table. This determines what kind of authority a person has.

If you are doing it, you will find that this design is too tedious. What if all the employees in the company have such permission, everyone should configure it? That is a very painful thing. So add a role table, group some people into one category, and then assign permissions to roles. Users under the role also have permissions.

The relationship between users and roles is that a user can correspond to multiple roles, and a role can correspond to multiple users. Many-to-many relationship.

Therefore, we need an intermediate table. I believe everyone is familiar with it, so there will be no doubt.

Application scenario

Once you have users and roles, you need to design application scenarios. For example, an application program has several modules (system module, project management module, sales module). A module like this is an application scenario, such as menus, actions, and so on.

Suppose that now that we have designed it, and the application scenario includes modules, menus, and operations, there should be the following six relationships:

A user can correspond to multiple modules, and a module can correspond to multiple users. Many-to-many relationship.

A user can correspond to multiple menus, and a menu can correspond to multiple users. Many-to-many relationship.

A user can correspond to multiple operations, and an operation can correspond to multiple users. Many-to-many relationship.

A role can correspond to multiple modules, and a module can correspond to multiple roles. Many-to-many relationship.

A role can correspond to multiple menus, and a menu can correspond to multiple roles. Many-to-many relationship.

A role can correspond to multiple operations, and an operation can correspond to multiple roles. Many-to-many relationship.

So set up six tables to maintain these six relationships.

There seems to be nothing wrong with the design. Yes, if you don't join a new relationship, you can already meet most of the needs.

But if it is, new relationships (requirements) tend to be added to the system. At this point, a new table needs to be created. The complexity of the system also increases.

As you can see, there are several problems with such a design:

The design of the data table is too complex

The solution to the system is too fixed.

Third, simplify the problem.

In different applications, you may come up with different requirements, after putting forward a new requirement, you may find that the original design has no way to implement, so you have to add a new table. This is also the problem mentioned above.

In fact, there is no need to think so complicated, permissions can be simply described as: so-and-so subject has so-and-so authority in so-and-so field.

The body can be a module, a page or a button on a page

Permissions can be a user, a role, or a department

The domain can be "visible", "read-only" or "available" (such as buttons can be clicked)

In fact, it is the problem of Who, What and How.

So the six tables mentioned above can actually design one table:

Fourth, an example is illustrated.

Let's use an example to illustrate the design. "users and roles use permissions on the page."

Detailed design:

1, put the configuration of the menu on the database, each menu for a unique coding MenuNo, each "leaf node" menu item for a page (url).

2. Put the configuration of the button on the database and belong to a menu item (actually hanging on a page). There should be several button groups on a page, such as two lists, both of which need to be "add, modify, delete". So you need to add a button grouped field to distinguish.

3. Assign menu permissions to users / roles. PrivilegeMaster is "User" or "Role", PrivilegeMasterValue is UserID or RoleID,PrivilegeAccess is "Menu", PrivilegeAccessValue is MenuNo,PrivilegeOperation and "enabled"

4. Assign button permissions to users / roles. PrivilegeMaster is "User" or "Role", PrivilegeMasterValue is UserID or RoleID,PrivilegeAccess is "Button", PrivilegeAccessValue is BtnID,PrivilegeOperation and "enabled"

5. If you need to disable the permissions of individual users, PrivilegeOperation is set to "disabled".

If you are not clear, you can look at the following picture:

Database design:

Thank you for your reading. the above is the content of "how to design the general rights management of the database". After the study of this article, I believe you have a deeper understanding of how to design the general rights management of the database. The specific use of the situation also needs to be verified by practice. Here is, the editor will push for you more related knowledge points of the article, welcome to follow!

Welcome to subscribe "Shulou Technology Information " to get latest news, interesting things and hot topics in the IT industry, and controls the hottest and latest Internet news, technology news and IT industry trends.