如何在PostgreSQL中实现业务逻辑权限？

我们假设我有一个项目表：

CREATE TABLE items
(
    item serial PRIMARY KEY,...
);

现在我想为每个项目引入“权限”的概念(注意,我不是在谈论数据库访问权限,而是在谈论该项目的业务逻辑权限).每个项目都具有默认权限以及可能覆盖默认权限的每用户权限.

我试着想办法实现这个,并想出了以下解决方案：

1)布尔解决方案

对每个权限使用布尔列：

CREATE TABLE items
(
    item serial PRIMARY KEY,can_change_description boolean NOT NULL,can_change_price boolean NOT NULL,can_delete_item_from_store boolean NOT NULL,...
);

CREATE TABLE item_per_user_permissions
(
    item int NOT NULL REFERENCES items(item),user int NOT NULL REFERENCES users(user),PRIMARY KEY(item,user),...
);

优点：每个权限都被命名.

缺点：有许多权限会显着增加列数,您必须定义两次(每个表一次).

2)整数解决方案

使用整数并将其视为位域(即位0表示can_change_description,位1表示can_change_price,依此类推,并使用按位运算来设置或读取权限).

CREATE DOMAIN permissions AS integer;

优点：非常快.

缺点：您必须跟踪哪个位代表数据库和前端接口中的哪个权限.

3)比特场解决方案

与2)相同,但使用bit(n).最有可能是相同的优点和缺点,也许稍微慢一点.

4)Enum解决方案

使用枚举类型进行权限：

CREATE TYPE permission AS ENUM ('can_change_description','can_change_price',.....);

然后为默认权限创建一个额外的表：

CREATE TABLE item_default_permissions
(
    item int NOT NULL REFERENCES items(item),perm permission NOT NULL,perm)
);

并将每用户定义表更改为：

CREATE TABLE item_per_user_permissions
(
    item int NOT NULL REFERENCES items(item),user,perm)    
);

优点：易于命名个人权限(您不必处理位位置).

缺点：即使只是检索默认权限,它也需要访问另外两个表：第一个是默认权限表,第二个是存储枚举值的系统目录.

特别是因为必须为该项目的每个页面视图检索默认权限,所以最后一个替代方案的性能影响可能很大.

你能想到其他选择吗？

应该采取哪种方法？

请注意：这个问题已经是reposted on DBA了.

解决方法

这实际上取决于您需要获得权限的级别

基于角色 – 非用户

基于用户 – (更难维护)

或两者的结合

用户和角色……

以下是我们的系统
用户表 – >包含UserNames等

角色=> Office支持,机械师等角色列表

安全等级 – >等级列表,例如只读,管理员

应用功能表 – >包含可以应用权限的函数,例如Can_Edit_Users

应用安全表 – >用户名应用程序功能ID,角色和任意位/是否为权限 – 或使用安全级别的更复杂角色级别的整数.

这提供了最大的灵活性,但可能难以构建UI.

在应用程序中,我们获取用户权限一次,并执行一项功能来检查他们是否具有权限

例如CurrentUser.HasPermissions( “Can_Edit_Users”)

public bool HasPermissions(string Permission)
{
return this.Permissions.Any(p=>p.FunctionName==Permission && IsAllowed==true);
}