使用 mySQL 的 3 层 Web 应用权限结构

Question

首先，我很抱歉这个问题有多长，感谢您抽出宝贵的时间阅读它！

我们目前正在开发我更喜欢将其描述为基于 Web 的平台，其中包含许多应用程序并且遇到了权限问题。这是我们业务的内部应用程序，不公开，因此我们有独特的需求。

我们不能使用严格的基于组的权限系统，因为它太笼统，限制性太强，一些员工需要访问多个应用程序，应用程序内的多个部门（有些可能称为组），每个部门内只有几个功能部。

我们还需要能够动态显示数据，因为我们正在为平台开发许多应用程序，我们需要能够在数据库中注册信息，然后它将填充适当的复选框并检查它们是否如果用户无权访问应用程序、部门或功能，则用户有权访问或将其留空。

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

1. 用户可以访问的应用程序
2. 用户可以访问的部门
3. 用户有权访问的特定功能

理论上这应该很简单，我相信最好的解决方案实际上会很简单，但我认为我们要么忽略了某些东西，要么过于仔细地观察了某些东西。

在我继续之前，我了解在现有结构中有多种方法可以处理这种情况，我们有 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 查询需要过于具体才能获取用户访问信息，而我们无法获得该功能的完整列表部门，没有NULL 值在它们应该返回的LEFT JOIN 中返回 - 这归因于一个特定字段，该字段在连接的多个表中具有通用名称，但每个表中的数据不同。我们指定了我们希望从每个查询返回的所有字段，但由于某种原因，这个 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

特定用户权限：保存用户可以执行的所有功能的列表，这与功能注册表相关联，将自身与部门注册表相关联，与应用程序注册表相关 p>

    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 工作异常的问题，我可能会建议我们使用一种简单的技术。我们只需为每个表及其字段添加一个唯一值即可。例如，表格：

apples：[id、brand、organic] 品牌：[id, name]

会变成：

app_apples: [app_id, appbrd_brand, app_organic] brd_brands: [brd_id, brd_name]

这完成了两件事。保证每个字段在整个系统中都是唯一的（因此应该可以解决所有JOIN 问题），并且还可以非常快速地查看和解决数据之间的关系。

只要我的两分钱。