PostgreSQL表空间、模式、表、用户/角色之间的关系

PostgreSQL表空间、模式、表、用户/角色之间的关系是本文咱们主要要介绍的内容，表空间，数据库，模式，表，用户，角色之间的关系究竟是怎样的呢？接下来咱们就开始介绍这一过程。

实验出角色与用户的关系

在PostgreSQL中，存在两个容易混淆的概念：角色/用户。之因此说这两个概念容易混淆，是由于对于PostgreSQL来讲，这是彻底相同的两个对象。惟一的区别是在建立的时候：

1.我用下面的psql建立了角色kanon：CREATE ROLE kanon PASSWORD 'kanon';接着我使用新建立的角色kanon登陆，PostgreSQL给出拒绝信息：FATAL： role 'kanon' is not permitted to log in.说明该角色没有登陆权限，系统拒绝其登陆。

2.我又使用下面的psql建立了用户kanon2:CREATE USER kanon PASSWORD 'kanon2';接着我使用kanon2登陆，登陆成功。难道这二者有区别吗？查看文档，又这么一段说明："CREATE USER is the same as CREATE ROLE except that it implies LOGIN."----CREATE USER除了默认具备LOGIN权限以外，其余与CREATE ROLE是彻底相同的。

为了验证这句话，修改kanon的权限，增长LOGIN权限：ALTER ROLE kanon LOGIN;再次用kanon登陆，成功！那么，事情就明了了：CREATE ROLE kanon PASSWORD 'kanon' LOGIN 等同于CREATE USER kanon PASSWORD 'kanon'.这就是ROLE/USER的区别。

数据库与模式的关系

模式（schema）是对数据库（database）逻辑分割。

在数据库建立的同时，就已经默认为数据库建立了一个模式--public，这也是该数据库的默认模式。全部为此数据库建立的对象（表、函数、试图、索引、序列等）都是常见在这个模式中的。
实验以下：

1.建立一个数据库dbtt----CREATE DATABASE dbtt;

2.用kanon角色登陆到dbtt数据库,查看dbtt数据库中的全部模式：/dn; 显示结果是只有public一个模式。

3.建立一张测试表----CREATE TABLE test(id integer not null);

4.查看当前数据库的列表： /d; 显示结果是表test属于模式public.也就是test表被默认建立在了public模式中。

5.建立一个新模式kanon，对应于登陆用户kanon：CREATE SCHEMA kanon OWNER kanon；

6.再次建立一张test表，此次这张表要指明模式----CREATE TABLE kanon.test (id integer not null);

7.查看当前数据库的列表： /d; 显示结果是表test属于模式kanon.也就是这个test表被建立在了kanon模式中。得出结论是：数据库是被模式(schema)来切分的，一个数据库至少有一个模式，全部数据库内部的对象(object)是被建立于模式的。用户登陆到系统，链接到一个数据库后，是经过该数据库的search_path来寻找schema的搜索顺序,能够经过命令SHOW search_path；具体的顺序，也能够经过SET search_path TO 'schema_name'来修改顺序。

官方建议是这样的：在管理员建立一个具体数据库后，应该为全部能够链接到该数据库的用户分别建立一个与用户名相同的模式，而后，将search_path设置为"$user"，
这样，任何当某个用户链接上来后，会默认将查找或者定义的对象都定位到与之同名的模式中。这是一个好的设计架构。

表空间与数据库的关系

数据库建立语句CREATE DATABASE dbname 默认的数据库全部者是当前建立数据库的角色，默认的表空间是系统的默认表空间--pg_default。
为何是这样的呢？由于在PostgreSQL中，数据的建立是经过克隆数据库模板来实现的，这与SQL SERVER是一样的机制。

因为CREATE DATABASE dbname并无指明数据库模板，因此系统将默认克隆template1数据库，获得新的数据库dbname。（By default, the new database will be created by cloning the standard system database template1）.

而template1数据库的默认表空间是pg_default，这个表空间是在数据库初始化时建立的，因此全部template1中的对象将被同步克隆到新的数据库中。
相对完整的语法应该是这样的：CREATE DATABASE dbname OWNER kanon TEMPLATE template1 TABLESPACE tablespacename;

下面咱们来作个实验验证一下：

1.链接到template1数据库，建立一个表做为标记：CREATE TABLE tbl_flag(id integer not null);向表中插入数据INSERT INTO tbl_flag VALUES (1);

2.建立一个表空间:CREATE TABLESPACE tskanon OWNER kanon LOCATION '/tmp/data/tskanon';在此以前应该确保目录/tmp/data/tskanon存在，而且目录为空。

3.建立一个数据库，指明该数据库的表空间是刚刚建立的tskanon：CREATE DATABASE dbkanon TEMPLATE template1 OWNERE kanon TABLESPACE tskanon;

4.查看系统中全部数据库的信息：/l；能够发现，dbkanon数据库的表空间是tskanon,拥有者是kanon;

5.链接到dbkanon数据库，查看全部表结构:/d;能够发现，在刚建立的数据库中竟然有了一个表tbl_flag,查看该表数据，输出结果一行一列，其值为1，说明，该数据库的确是从template1克隆而来。

仔细分析后，不可贵出结论：在PostgreSQL中，表空间是一个目录，里面存储的是它所包含的数据库的各类物理文件。

总结：

表空间是一个存储区域，在一个表空间中能够存储多个数据库，尽管PostgreSQL不建议这么作，但咱们这么作彻底可行。一个数据库并不知直接存储表结构等对象的，而是在数据库中逻辑建立了至少一个模式，在模式中建立了表等对象，将不一样的模式指派该不一样的角色，能够实现权限分离，又能够经过受权，实现模式间对象的共享，而且，还有一个特色就是：public模式能够存储你们都须要访问的对象。

这样，咱们的网就造成了。但是，既然一个表在建立的时候能够指定表空间，那么，是否能够给一个表指定它所在的数据库表空间以外的表空间呢？答案是确定的!这么作彻底能够：那这不是违背了表属于模式，而模式属于数据库，数据库最终存在于指定表空间这个网的模型了吗？！是的，看上去这确实是不合常理的，但这么作又是有它的道理的，并且现实中，咱们每每须要这么作：将表的数据存在一个较慢的磁盘上的表空间，而将表的索引存在于一个快速的磁盘上的表空间。

但咱们再查看表所属的模式仍是没变的，它依然属于指定的模式。因此这并不违反常理。实际上，PostgreSQL并无限制一张表必须属于某个特定的表空间，咱们之因此会这么认为，是由于在关系递进时，偷换了一个概念：模式是逻辑存在的，它不受表空间的限制。

关于PostgreSQL表空间、模式、表、用户/角色之间的关系的相关知识就介绍到这里了，但愿本次的介绍可以对您有所收获！