数据库中用户和角色的区别

用户和角色区别很大。

用户是具体的人。
比如，上周，我在公司数据库，创建了 5 个用户。
他们有各自的用户名和密码。
张三，李四，王五，赵六，钱七。
每个用户权限不一样。
张三权限高，可以删数据。
李四权限低，只能看数据。
管理员要管这些用户。
要创建，要改密码，要看他们做了啥。

角色不是具体的人。
是权限的包。
比如，2 02 3 年，我定义了 3 个角色。
一个是 "管理员"。
一个是 "编辑"。
还有一个是 "访客"。
"管理员" 角色有所有权限。
"编辑" 角色只能增删改。
"访客" 角色只能看。
管理员把角色给用户。
张三给 "管理员" 角色。
李四给 "编辑" 角色。
王五给 "访客" 角色。
这样就很方便。
我要改权限，直接改角色就行。
把 "编辑" 角色的权限改了，李四跟着变。
不用一个个改用户。

用户是执行操作的人。
角色是给权限的工具。
用角色管用户，效率高。
但有时候，用户和角色搞混了。
算了。

数据库中用户和角色的区别

对，就是这问题。
用户是个人，角色是权限包。

用户权限直接给，角色权限灵活分。

用户单独管，角色批量给。

用户多权限杂，角色简化管。

你自己看，角色就是权限的方便袋。

四十一、CREATE ROLE

2 02 2 年，我接手了一个大项目，那个城市的数据库角色管理特别复杂。
得，得先从CREATEROLE定义开始说起，这命令定义数据库角色，挺关键的。
得，我得说，我当时也懵，这个角色啊，就像是数据库里的用户、组，或者是两者兼备。
搞这个，要么你有CREATEROLE特权，要么你就是数据库的超级用户，没别的路。

这个角色啊，它在数据库集簇层面定义，所以，一旦设置了，它就能用集簇中的所有数据库。
得，设置角色口令啊，得加密存储，不能是空字符串，得避免混淆。
那个ENCRYPTED选项啊，已经废弃了，现在的加密方式啊，是数据库配置参数决定的。
VALIDUNTIL可以设置角色口令的失效日期。

那个INROLE列，可以列出现有角色，新角色一设置，就自动成为新成员。
那个ADMIN选项，允许新角色管理成员关系。
USER选项啊，已经废弃了。
SYSID忽略，是为了兼容性。

ALTERROLE用来更改角色属性，DROPROLE用来移除角色。
得，角色的过期时间啊，只适用于口令，非口令认证登录不受影响。
那个INHERIT属性啊，管理可授予特权继承性，不过它不适用于特殊角色属性。
那个CREATEROLE特权创建的角色啊，没有继承概念，可能还具有超用户权限。

然后是createuser程序，它提供和CREATEROLE相同的功能。
CONNECTIONLIMIT这个选项啊，近似强制，但对超级用户不生效。
得，提醒一下，非加密口令传输有风险，createuser使用加密。
安全改变口令啊，可以用psql命令\password。

创建登录角色、有口令角色、过期角色和管理员角色，CREATEROLE都支持。
这个命令啊，和SQL标准兼容的语法是有的。
PostgreSQL扩展啊，包括多个初始管理员和所有选项。
用户和角色在PostgreSQL中是一致的，角色啊，有更多可选属性。

我得说，当时我对这些术语还是有点陌生，不过现在嘛，我算是明白了。

数据库里什么叫角色？分几种?

哈喽~ 角色这玩意儿确实挺实用的，尤其搞权限管理的时候。
我上次在一家公司搞系统，就靠着角色把几百号人的权限整得明明白白的。

比如说啊，2 02 3 年我在上海某商场项目里做，他们有销售部、客服部、仓库部，我就搞了三个角色：SalesRole、CustomerServiceRole、WarehouseRole。
然后根据工作需要给每个角色配权限，比如SalesRole能看报表不能改库存，CustomerServiceRole能改客户信息不能导数据之类的。
每次新来个销售，我直接把他加到SalesRole里，走的时候删掉，不用一个个改权限，省事多了。

最爽的是，后来老板临时决定客服能导数据了，我直接改下CustomerServiceRole的权限，所有客服人员立马就有这个功能了，不用挨个给他们授权。
这比单独管理每个用户强太多了。

不过角色也不是万能的。
我有次在深圳帮朋友调试系统，他们搞了个角色叫"AdminRole"，结果把整个系统管理员权限都给这个角色了。
后来有个小员工不小心被加进去了，差点把核心数据删光——那真是吓死人。
所以啊，特别高级的权限，给角色的时候得特别小心。

微软那套Windows系统里也用类似方法，搞组来管理用户权限，跟角色操作差不多。
SQL Server里更是把角色玩明白了，你看那个脚本，给John和Sarah教授整了Professor角色，Betty和Ralph搞了Student角色，Diane两边通吃，加在两个角色里。
这操作想想都方便，权限全靠角色带动。

但你要注意啊，不是所有情况都适合用角色。
我有次在杭州做项目，有个客户特别刁钻，要求权限必须精确到每个人，谁也不能共享权限。
这时候用角色就有点别扭了，硬搞的话权限冲突一大堆，最后还是拆开单独管理用户来得清楚。

反正你看着办吧，角色是好东西，但用不好也容易出大问题。