database - 访问权限数据库设计

Question

哪一种模式更适合设计用于存储访问权限的数据库？

1. 演员 {演员 ID，姓名，密码，canpost，cancomment，canremoveuser，candothis，candothat}
2. actor {actorid, name, password} 权限 {actorid, action, isallowed}

Answer 1

您的第一个选项没有它应有的灵活，而您的第二个选项则没有应有的可管理性。

访问控制的标准模式称为基于角色的安全性。随着用户数量和您需要的不同类型权限数量的增长，您的用户到权限链接的管理可能会变得越来越困难。

例如，如果您有 5 个管理员和 50 个用户，您如何使每个组的权限保持同步？当您的一位用户被提升为管理员时，您需要进行多少次编辑？答案是创建两个交集：users-to-roles和roles-to-permissions。

Answer 2

选项 1 适用于简单系统。一个查询，为您提供一排您需要的所有信息。这是非常有效的。效率是“好”的。它甚至可能符合您的需求“更好”。

如果操作权限很可能随着时间的推移以不可预测的方式扩展，并且由本质上孤立的模块使用，以确认用户只能访问其独特的子系统，则选项 2 非常有用。更复杂的是，如果同时检索参与者和访问信息，则必须执行“加入”。但我喜欢加入，所以我不会大声说效率低下，而星展银行是为擅长它们而构建的。明智地使用索引，它们就很好。

从编码的角度来看，使用链接表更复杂。您已经隔离了数据，因此必须编写更复杂的代码来处理数据的每个不同部分。但是，我个人认为这是“很好”的复杂性，因为每个独特的数据都有自己独特的依赖代码。允许模块化和一元封装功能。

Answer 3

我认为在大多数情况下，解决方案#2 要好得多。我会丢弃该解决方案中的“isallowed”标志，只将用户的给定权限插入权限表中。