在数据库中保存模块化用户权限

Question

我有一个PHP MySQL应用程序，它采用模块化设计。现在总共有大约5个模块，我真的预计不会超过10个。

我目前有两种类型的用户 - “用户和管理员”。这些用户类型具有相同的权限，但管理员可以编辑用户，而普通用户则不能。

我想实现模块化permssions，这样如果您是管理员，则您有权在所有模块中进行更改。如果您是普通用户，则可以设置用户可以访问的模块（即一组复选标记）。

我的问题是，在数据库中存储它的最佳方法是什么？我已经有了一个Users表。我已经提出了以下3个解决方案，我想知道是否有推荐的方法来做或者有其他方法。我还需要记住，在将应用程序升级到新版本时，我必须为当前在数据库中的所有用户设置权限。当集成新模块时，我还必须能够为每个用户轻松添加默认烫发。我正在寻找易于维护和实施的东西，但是可以灵活地添加更多模块。

到目前为止我的头脑风暴选项：

1. 使用位掩码类型字符串的列中的Users表中存储perms：10001表示它们仅具有“模块A”和“模块E”的权限。
2. 在一个列中的Users表中存储perms，其中包含用户具有权限的模块名称的分隔（逗号或管道）列表：“ModuleA，ModuleE”。
3. 为用户perms创建一个单独的表，如下所示：

UserId  | Module  | Permission
1       | A       | 1
1       | B       | 0

您怎么看？

Answer 1

  

    

使用位掩码类型字符串的列中的Users表中存储perms：10001表示它们仅具有“模块A”和“模块E”的权限。

  

您需要做一个位掩码测试，以确定用户是否有特定的模块中的权限，只允许两个选项（允许/不允许），以便减少您的选择，随后扩大权限。

  

    

在一个列中的Users表中存储perms，其中包含用户具有权限的模块名称的分隔（逗号或管道）列表：“ModuleA，ModuleE”。

  

在VARCHAR中使用单独的列表总是会增加开销以识别您想要的权限（这里有关于该主题的无数问题）

  

    

为用户perms创建一个单独的表，如下所示：

  

最简单的方法。简单的SQL查询可以提取信息，范围可以扩展未来的权限范围

Answer 2

听起来你只是跟踪访问而不是细粒度权限，这很好。

  

使用位掩码类型字符串的列中的Users表中存储perms：10001表示它们仅具有“模块A”和“模块E”的权限。

我强烈建议不要这样做。数据库中的位掩码是维护的噩梦。对于另一个开发人员而言，每个比特的含义代表什么并不是很明显。

  

在一个列中的Users表中存储perms，其中包含用户具有权限的模块名称的分隔（逗号或管道）列表：“ModuleA，ModuleE”。

这是仅使用分隔符的第一个解决方案的变体。同样，我强烈建议反对它，因为它是一个维护头痛。

  

为用户perms创建一个单独的表，如下所示：

这是我推荐的解决方案。最大的原因是它比其他的更具可扩展性，并且更易于维护。如果您想创建一个维护屏幕来控制权限，那么使用这种方法将是微不足道的。您可以轻松添加模块，更改模块的顺序，然后扩展表中维护的内容（例如，您可能稍后将“只读”作为列添加为与简单访问模块的能力不同）。此外，这种方法可以更轻松地从表中提取信息。 “谁可以访问模块X？”用这个写一个简单的查询，使用分隔列表或位掩码更难。

Answer 3

我为我工作的桌面应用程序执行类似的操作。我认为将用户权限存储在看起来像这样的表中是很好的。

UserId | ModuleA | ModuleB| ... |ModuleN
1      |       1 |       0| ... |      0

我认为这提供了一些关于你正在做什么的更清晰，如果你需要经常更新你的表，你可以添加大量的模块，但是做位掩码的方法可能并不坏想法也是。

Answer 4

我公司的应用程序使用与按位解决方案一致的稍微不同的方法 - 用户访问值。这是用户表中的一个简单的int字段，它告诉应用程序用户可以访问哪些权限（还有另一个表包含UI的简单定义，但出于所有实际目的，应用程序只能看到一个数字）在我们使用的示例中，超级管理员是权限9999，底层成员为级别1000.访问级别以100个数字为增量添加，因此如果需要添加另一个，则无需级联更新。在用户类中，我们只询问用户的访问级别是否大于访问每个单独模块的定义级别。因此，例如，如果可以编辑文档的最低级别用户是3000而某人是超级管理员，系统将检查他们的权限是否大于3000（它是9999）然后将返回true允许权限。简单。

当然，有更多的模块化系统，但是当我们仔细分析我们的产品和未来的计划时，没有必要添加一对多的类型表来处理我们的解决方案。虽然我们确实拥有相当多的不同访问级别，但它们的定义非常明确，而且商业模式不太可能添加许多新选项。真的，重要的是要问自己你真正需要走多远......如果它不需要具有数十个或数百个不同级别的权限的超级强大，为什么要增加额外表，查询，代码的开销，等你的应用程序？听起来你现在正在做的事情非常简单。