用户认证和权限表结构
我正在创建一个用户身份验证库(用于练习)。
我要添加的一件事是,一个用户可以分配给多个角色。
每个角色都有一组权限(例如 editUser、createUser 等)。
如果用户属于两个组,并且任何组有权执行某项操作,则该用户可以执行该操作。
我想知道从 mysql 数据库的角度存储这些信息的最佳方法。
我在想
users : ID | username | etc
groups : ID | name | etc
user_group : group_ID | user_ID
permissions : ID | name | description (lookup table)
group_permission : permission_ID | group_ID
,基本上,如果一个组拥有权限,那么它就会在 group_permission 中获得一个条目。
我的问题是,这是最有效的方法吗?或者我最好将每个权限作为组表中的一列并删除 group_permission 表?
I am creating a user authentication library (for the exercise).
One of the things I am adding is is, a user can be assigned to multiple roles.
Each role has set of permissions (think editUser, createUser etc).
If a user is part of two groups if any group has permission to do an action then the user can do the action.
I am wondering the best way to store this information from a mysql database point of view.
I was thinking
users : ID | username | etc
groups : ID | name | etc
user_group : group_ID | user_ID
permissions : ID | name | description (lookup table)
group_permission : permission_ID | group_ID
and basically if a group has a permission then it gets an entry in group_permission.
My question is, is this the most productive way to do this, or would I be better to have each permission as a column in the groups table and drop the group_permission table?
如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱,如果其他用户或者作者回复了您的评论,将不能在第一时间通知您!
发布评论
评论(1)
你的方法看起来不错并且标准化,对此表示赞赏。
我缺少的一件事是非权限表,即不允许执行操作的表。
Active Directory 具有此功能,这使您可以快速阻止对对象的权限。
这允许您允许访问所有帐户,除了......
如果您以相反的方式执行此操作,则必须允许访问每个对象,同时忽略 HR 数据。
第一种方式设置 2 个对象的权限(1 个对父对象的权限,1 个对子对象的解雇),第二种方式可能会遇到数十个权限。
就我个人而言,我会更新
权限
表以也包括排除项。这将允许您将排除项附加到组和用户。
使用黑洞表来简化新权限的添加
为了简化添加新权限的过程,您可以创建一个新的黑洞表。
这不会存储任何内容,但会触发一个触发器来为您执行插入操作,通过这种方式,您可以隐藏数据库已从插入代码中标准化的事实。
现在您可以插入指定组或 user_id 的表
,并有一个触发器来处理技术细节:
You approach looks nice and normalized, kudos for that.
One thing that I'm missing is a non-permission table, i.e. a table that disallows actions.
Active directory has this and this allows you to quickly block permissions to an object.
This allows you to allow access to all accounts, except .....
If you do it the other way round, you have to allow access to each object whilst leaving out the HR data.
The first way sets permissions on 2 objects (1 permission on parent, 1 dismissal on child), the second way can run into dozens of permissions.
Personally I would update the
permissions
table to also include exclusions.This would allow you to attach exclusions to both groups and users.
Use a blackhole table to simplify addition of new permissions
In order to simplify adding new permissions, you can create a new blackhole table.
This does not store anything, but will fire a trigger instead that does the insertion for you, in this manner you can hide the fact that your DB is normalized from the insertion code.
Now you can insert into the table specifying either group or user_id
And have a trigger to handle the technical details: