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表空間、模式、表、用戶/角色之間的關係的相關知識就介紹到這裏了，但願本次的介紹可以對您有所收穫！