基于mySQL的3层web应用权限结构

Question

首先也是最重要的，我很抱歉这个问题有这么长的时间，并感谢您的时间阅读它！

我们目前正在开发一个基于web的平台，它包含了许多应用程序，并且遇到了权限问题。这是我们业务的内部应用程序，不是公开的，因此我们有独特的需求。

我们不能使用严格的基于组的权限系统，因为它太笼统，限制太大，一些工作人员将需要访问多个应用程序，在应用程序中需要多个部门(有些可能称为组)，每个部门内只需要少数几个功能。

我们还需要能够动态显示数据，因为我们正在为平台开发许多应用程序--我们需要能够在数据库中注册信息--然后它将填充适当的复选框，并在用户没有访问应用程序、部门或功能的情况下检查它们。

出于这些原因，我们需要3层权限，这些权限包括

1. 的应用程序，用户可以访问

，

1. ，部门，用户可以访问
2. 的特定功能，用户可以访问

从理论上讲，这应该非常简单，我相信最好的解决方案实际上会很简单，但我认为我们要么忽略了某些东西，要么看得太近了。

在我更进一步之前，我了解到在它现有的结构中有很多方法来处理这种情况，我们有6种运行和正确的工作，但是这些方法使用的是“不寻常的”方法，我们确实需要一个更好的解决方案，我相信这是从数据库设计开始的。

目前，我们已经尝试了一个3表系统，该系统具有以下与权限相关的表

应用程序寄存器：--它包含平台内所有应用程序的列表

    app_id (primary AI) | perm_id (int) | app_name | app_code | app_location | tab_location | access_key

应用程序权限寄存器：--它包含每个应用程序的每个权限的列表，不管它是应用程序、部门还是功能(在下面的access_type中定义)

    permission_id (primary AI) | perm_id (int) | app_id | permission_code | permission_name | permission_description | access_type

特定用户权限：持有与应用程序、部门和功能相关的特定权限

    permission_id (primary AI) | perm_id (varchar) | app_permission_id | app_id | user_id | access_status | function_code

问题在于分配权限，因为当我们深入到一个函数级别时，我们发现mySQL查询需要过于具体才能获得用户访问信息，而且我们无法获得该部门的全部函数列表，因此在LEFT JOIN中不返回它们应该返回的NULL值--这归因于一个特定字段，该字段在被连接的多个表中有一个公共名称，但每个表中的数据不同。我们指定了从每个查询中返回的所有字段，但是由于某种原因，这个1字段不断出现，并且正在加入错误的数据。

因此，我正在考虑实现以下结构：

应用程序寄存器：用于保存具有URI和导航系统引用的所有应用程序的列表

    app_id (primary AI) | app_name | app_uri | app_tab

部门注册：保存所有部门的列表以及与应用程序的关系

    dept_id (primary AI) | app_id | dept_name

函数寄存器：保存所有功能的列表和与某个部门的关系，部门在“部门注册”中与申请有关。

   function_id (primary AI) | dept_id | function_name | function_description

特定的用户权限：保存用户可以执行的所有功能的列表，这与函数寄存器相关联，与部门注册相关联，与应用程序寄存器相关。

    permission_id (primary AI) | user_id (index) | function_id | permission_status (int - 0 = not allowed access | 1 = allowed access)

编辑启动

我刚刚意识到，在特定的用户权限表中有些地方不太正确，如上面所示，我没有考虑应用程序或部门权限，所以这看起来怎么样？

我已经将function_id更改为permit_item，以保存项目的ID，然后在permit_type中添加以定义它是否是用户可以访问的应用程序、部门或函数。

    permission_id (primary AI) | user_id (index) | permit_item | permit_type | permission_status (int - 0 = not allowed access | 1 = allowed access)

编辑端

从这里开始，我们可以在一个查询中做一些连接，例如(只是为了演示这个概念，我意识到这不是正确的查询，也不是在生产中编写它的最佳方式)。

    SELECT * FROM app_register 
    JOIN dept_register ON app.register.app_id=dept_register.app_id
    JOIN function_register ON dept_register.dept_id=function_register.dept_id
    JOIN user_permissions ON app_register.app_id=user_permissions.app_id
    WHERE user_permissions.user_id='1'

这将为我提供一个简化的联合权限表，该表涉及所有功能、部门和应用程序，然后列出用户可以访问的应用程序。

但我需要公正的观察者的意见，而不是情绪化的数据库设计师和他的朋友。

有什么东西我忽略了或者看得太重了吗？

我们是否可以尝试另一种更好的结构来处理这些数据？

我真的很感谢大家的帮助，并再次为这个问题的长度感到抱歉！

Answer 1

你提出的解决方案对我来说似乎最有意义。

关于LEFT JOIN的问题，我可能会建议我们使用一种简单的技术。我们只是在每个表及其字段前加上一个唯一的值。例如，表：

苹果: id，品牌，有机品牌: id，名称

将成为：

app_apples: app_id，appbrd_brand，app_organic brd_brands: brd_id，brd_name

这完成了两件事。每个字段在整个系统中都是唯一的(因此应该解决所有的JOIN问题)，而且数据之间的关系也可以很快地被看到和解决。

只有我的两分钱。