1

我有以下表结构：

Entity
---------------------
id | name

Users
---------------------
id | name | password 

UserGroups
---------------------
id | parent_id | name

Users_UserGroups
---------------------
user_id | user_group_id

Roles
---------------------
id | parent_id | name

Users_Roles
--------------------
user_id | role_id

主要目标是创建Entity具有以下条件的行级访问限制：

1) 用户创建Entity- 他可以看到它（他是所有者）
2) 用户组成员也可以看到它（但如果其他定义 - 看不到 - 它将是用户私有的）。所以记录可以是用户或组私有的，也可以是公共的——所有人都可以看到记录。例如，用户在销售团队 A 中，有记录可以看到所有组成员，但可能有一个或多个记录只能看到用户 - 可能是潜在客户。
3) 例如，用户 A 是角色salesman，并且该角色是父角色的子角色sales managers。然后作为sales manager角色的用户可以看到用户 A 实体。角色的层次结构。老板可以看到他的直接员工在做什么:)
4) 也会有profile表格，可以将配置文件添加到角色，如果需要，也可以添加到用户。

主要问题是如何将用户/组/角色/配置文件与实体相关联？以及如何定义权限？我的想法是在Entity. 查询Entity记录时，查找用户，查看用户属于哪个角色、组、个人资料等。但我认为它太复杂了，也许有更简单的方法，不需要很多额外的表。我将不胜感激：）

4

1 回答 1

1

标准模式是将 Principal 定义为您可以分配权限的任何内容。那么用户、用户组和角色都是主体的例子。一种实现方法是使用 principal_id 作为主键的主体表，然后通过 user_id 将用户表关联到它，通过 role_id 关联角色表，通过 user_group_id 关联组表。

然后，您将在实体上有一个 entity_owner_principal_id 列，以及一个带有 entity_id、principal_id 的 entity_permissions 表。您可以在此表中添加诸如“读取”、“删除”、“更新”之类的列，或者使用更灵活的内容。

您可能还想考虑组和角色之间是否存在任何真正的区别，它们都是对用户进行分组的方式，而且您似乎在这两种方式中也有层次结构。

于 2012-11-18T22:54:10.483 回答