PostgreSQL 作为世界上最抢先的开源数据库，有一套强大的用户人物权限体系，和 MySQL 做一个比照：
但硬币的另一面则是关于简略场景来说增加了杂乱度。在许多单运用场景，其实也不需求额定的 schema 层，也不需求额定的 owner。相信玩过 PG 的同学都碰到过类似 must be owner of table 的问题。
场景说明
咱们就来说说简略的 PG 运用场景，数据库用户该怎么配。所谓简略是指：
- PG 实例就一个数据库
- 数据库就一个默许的 public schema
- 一切的表都在这个 public schema 下
而运用数据库的场景，由人到数据库，和运用到数据库两部分组成：
-
人到数据库
- DBA 操作
- 数据库改变，DDL 和 DML 都有
- 数据库查询
-
运用到数据库
- 数据库改变，DDL 的话通常在运用启动前做，除此之外都是 DML
- 数据库查询
具体装备
最简略粗犷的当然是一个 superuser 搞定。本地装置 postgres 的话，第一个 postgres 用户其实便是这样的 superuser。
咱们把人和运用拆开，假如运用在启动时仍是需求改变 schema，则是下面这样
假如数据库 schema 改变发布现已和运用独立开来了，那么运用只需求有根本的数据库读写操作
到了这步假如除了 DBA 之外的人想拜访数据库的话，直接把 DBA 用户交出去危险太大了，所以这时会选择引入像 Bytebase 这样的工具。DBA 在 Bytebase 上装备普通用户的数据库拜访权限，而不用把用户名密码交出去。而且 schema 改变也能够在 Bytebase 上完成，这样大大减少了需求运用 DBA 账号直接操作数据库的情况，降低危险。
Pigsty 作为开箱即用的 PG 发行版，也预置了一套类似的默许人物。
额定留意
- 公有云数据库服务是不提供 superuser 的，他们只提供一个阉割版的 superuser，比方 Google Cloud SQL 里的 cloudsqlsuperuser
-
设置独自 migration 用户的原因一方面是为了便利监控，另一方面也使得咱们能够给 migration 用户设置独自的默许衔接参数，最常见设置的是 lock_timeout。要设置的原因是，做 DDL 时要加锁，加锁需求等候，而因为 PG 的行列机制，即使后边来的别的一条事务不需求 DDL 锁，一样会被 block 住。所以 migration 用户往往要设置一个 lock_timeout，防止长时间 block 后边的其他事务。
-
在 Postgres 里创建目标时，比方建表，建出来表的 owner 便是建表句子的执行者。所以当运用一个独自的 migration 用户来做 schema 改变时，表的 owner 也会是 migration。假如希望 owner 能反应具体的事务，比方说 payment 的话，那么能够再独自创建一个 payment 的人物，在 migration 执行的时分，运用 SET LOCAL ROLE 切换到 payment 再执行。
PostgreSQL 的用户人物体系仍是有点杂乱的，假如有什么其他额定建议和需求留意的地方，欢迎我们留言。
更多资讯，请关注 Bytebase 公号：Bytebase
