PostgreSQL表空間、模式、表、用戶(hù)/角色之間的關(guān)系是本文我們主要要介紹的內(nèi)容，表空間，數(shù)據(jù)庫(kù)，模式，表，用戶(hù)，角色之間的關(guān)系到底是怎樣的呢？接下來(lái)我們就開(kāi)始介紹這一過(guò)程。

實(shí)驗(yàn)出角色與用戶(hù)的關(guān)系

在PostgreSQL中，存在兩個(gè)容易混淆的概念：角色/用戶(hù)。之所以說(shuō)這兩個(gè)概念容易混淆，是因?yàn)閷?duì)于PostgreSQL來(lái)說(shuō)，這是完全相同的兩個(gè)對(duì)象。唯一的區(qū)別是在創(chuàng)建的時(shí)候：

1.我用下面的psql創(chuàng)建了角色kanon：CREATE ROLE kanon PASSWORD 'kanon';接著我使用新創(chuàng)建的角色kanon登錄，PostgreSQL給出拒絕信息：FATAL： role 'kanon' is not permitted to log in.說(shuō)明該角色沒(méi)有登錄權(quán)限，系統(tǒng)拒絕其登錄。

2.我又使用下面的psql創(chuàng)建了用戶(hù)kanon2:CREATE USER kanon PASSWORD 'kanon2';接著我使用kanon2登錄，登錄成功。難道這兩者有區(qū)別嗎？查看文檔，又這么一段說(shuō)明："CREATE USER is the same as CREATE ROLE except that it implies LOGIN."----CREATE USER除了默認(rèn)具有LOGIN權(quán)限之外，其他與CREATE ROLE是完全相同的。

為了驗(yàn)證這句話，修改kanon的權(quán)限，增加LOGIN權(quán)限：ALTER ROLE kanon LOGIN;再次用kanon登錄，成功！那么，事情就明了了：CREATE ROLE kanon PASSWORD 'kanon' LOGIN 等同于CREATE USER kanon PASSWORD 'kanon'.這就是ROLE/USER的區(qū)別。

數(shù)據(jù)庫(kù)與模式的關(guān)系

模式（schema）是對(duì)數(shù)據(jù)庫(kù)（database）邏輯分割。

在數(shù)據(jù)庫(kù)創(chuàng)建的同時(shí)，就已經(jīng)默認(rèn)為數(shù)據(jù)庫(kù)創(chuàng)建了一個(gè)模式--public，這也是該數(shù)據(jù)庫(kù)的默認(rèn)模式。所有為此數(shù)據(jù)庫(kù)創(chuàng)建的對(duì)象（表、函數(shù)、試圖、索引、序列等）都是常見(jiàn)在這個(gè)模式中的。
實(shí)驗(yàn)如下：

1.創(chuàng)建一個(gè)數(shù)據(jù)庫(kù)dbtt----CREATE DATABASE dbtt;

2.用kanon角色登錄到dbtt數(shù)據(jù)庫(kù),查看dbtt數(shù)據(jù)庫(kù)中的所有模式：/dn; 顯示結(jié)果是只有public一個(gè)模式。

3.創(chuàng)建一張測(cè)試表----CREATE TABLE test(id integer not null);

4.查看當(dāng)前數(shù)據(jù)庫(kù)的列表： /d; 顯示結(jié)果是表test屬于模式public.也就是test表被默認(rèn)創(chuàng)建在了public模式中。

5.創(chuàng)建一個(gè)新模式kanon，對(duì)應(yīng)于登錄用戶(hù)kanon：CREATE SCHEMA kanon OWNER kanon；

6.再次創(chuàng)建一張test表，這次這張表要指明模式----CREATE TABLE kanon.test (id integer not null);

7.查看當(dāng)前數(shù)據(jù)庫(kù)的列表： /d; 顯示結(jié)果是表test屬于模式kanon.也就是這個(gè)test表被創(chuàng)建在了kanon模式中。得出結(jié)論是：數(shù)據(jù)庫(kù)是被模式(schema)來(lái)切分的，一個(gè)數(shù)據(jù)庫(kù)至少有一個(gè)模式，所有數(shù)據(jù)庫(kù)內(nèi)部的對(duì)象(object)是被創(chuàng)建于模式的。用戶(hù)登錄到系統(tǒng)，連接到一個(gè)數(shù)據(jù)庫(kù)后，是通過(guò)該數(shù)據(jù)庫(kù)的search_path來(lái)尋找schema的搜索順序,可以通過(guò)命令SHOW search_path；具體的順序，也可以通過(guò)SET search_path TO 'schema_name'來(lái)修改順序。

官方建議是這樣的：在管理員創(chuàng)建一個(gè)具體數(shù)據(jù)庫(kù)后，應(yīng)該為所有可以連接到該數(shù)據(jù)庫(kù)的用戶(hù)分別創(chuàng)建一個(gè)與用戶(hù)名相同的模式，然后，將search_path設(shè)置為"$user"，
這樣，任何當(dāng)某個(gè)用戶(hù)連接上來(lái)后，會(huì)默認(rèn)將查找或者定義的對(duì)象都定位到與之同名的模式中。這是一個(gè)好的設(shè)計(jì)架構(gòu)。

表空間與數(shù)據(jù)庫(kù)的關(guān)系

數(shù)據(jù)庫(kù)創(chuàng)建語(yǔ)句CREATE DATABASE dbname 默認(rèn)的數(shù)據(jù)庫(kù)所有者是當(dāng)前創(chuàng)建數(shù)據(jù)庫(kù)的角色，默認(rèn)的表空間是系統(tǒng)的默認(rèn)表空間--pg_default。
為什么是這樣的呢？因?yàn)樵赑ostgreSQL中，數(shù)據(jù)的創(chuàng)建是通過(guò)克隆數(shù)據(jù)庫(kù)模板來(lái)實(shí)現(xiàn)的，這與SQL SERVER是同樣的機(jī)制。

由于CREATE DATABASE dbname并沒(méi)有指明數(shù)據(jù)庫(kù)模板，所以系統(tǒng)將默認(rèn)克隆template1數(shù)據(jù)庫(kù)，得到新的數(shù)據(jù)庫(kù)dbname。（By default, the new database will be created by cloning the standard system database template1）.

而template1數(shù)據(jù)庫(kù)的默認(rèn)表空間是pg_default，這個(gè)表空間是在數(shù)據(jù)庫(kù)初始化時(shí)創(chuàng)建的，所以所有template1中的對(duì)象將被同步克隆到新的數(shù)據(jù)庫(kù)中。
相對(duì)完整的語(yǔ)法應(yīng)該是這樣的：CREATE DATABASE dbname OWNER kanon TEMPLATE template1 TABLESPACE tablespacename;

下面我們來(lái)做個(gè)實(shí)驗(yàn)驗(yàn)證一下：

1.連接到template1數(shù)據(jù)庫(kù)，創(chuàng)建一個(gè)表作為標(biāo)記：CREATE TABLE tbl_flag(id integer not null);向表中插入數(shù)據(jù)INSERT INTO tbl_flag VALUES (1);

2.創(chuàng)建一個(gè)表空間:CREATE TABLESPACE tskanon OWNER kanon LOCATION '/tmp/data/tskanon';在此之前應(yīng)該確保目錄/tmp/data/tskanon存在，并且目錄為空。

3.創(chuàng)建一個(gè)數(shù)據(jù)庫(kù)，指明該數(shù)據(jù)庫(kù)的表空間是剛剛創(chuàng)建的tskanon：CREATE DATABASE dbkanon TEMPLATE template1 OWNERE kanon TABLESPACE tskanon;

4.查看系統(tǒng)中所有數(shù)據(jù)庫(kù)的信息：/l；可以發(fā)現(xiàn)，dbkanon數(shù)據(jù)庫(kù)的表空間是tskanon,擁有者是kanon;

5.連接到dbkanon數(shù)據(jù)庫(kù)，查看所有表結(jié)構(gòu):/d;可以發(fā)現(xiàn)，在剛創(chuàng)建的數(shù)據(jù)庫(kù)中居然有了一個(gè)表tbl_flag,查看該表數(shù)據(jù)，輸出結(jié)果一行一列，其值為1，說(shuō)明，該數(shù)據(jù)庫(kù)的確是從template1克隆而來(lái)。

仔細(xì)分析后，不難得出結(jié)論：在PostgreSQL中，表空間是一個(gè)目錄，里面存儲(chǔ)的是它所包含的數(shù)據(jù)庫(kù)的各種物理文件。

總結(jié)：

表空間是一個(gè)存儲(chǔ)區(qū)域，在一個(gè)表空間中可以存儲(chǔ)多個(gè)數(shù)據(jù)庫(kù)，盡管PostgreSQL不建議這么做，但我們這么做完全可行。一個(gè)數(shù)據(jù)庫(kù)并不知直接存儲(chǔ)表結(jié)構(gòu)等對(duì)象的，而是在數(shù)據(jù)庫(kù)中邏輯創(chuàng)建了至少一個(gè)模式，在模式中創(chuàng)建了表等對(duì)象，將不同的模式指派該不同的角色，可以實(shí)現(xiàn)權(quán)限分離，又可以通過(guò)授權(quán)，實(shí)現(xiàn)模式間對(duì)象的共享，并且，還有一個(gè)特點(diǎn)就是：public模式可以存儲(chǔ)大家都需要訪問(wèn)的對(duì)象。

這樣，我們的網(wǎng)就形成了。可是，既然一個(gè)表在創(chuàng)建的時(shí)候可以指定表空間，那么，是否可以給一個(gè)表指定它所在的數(shù)據(jù)庫(kù)表空間之外的表空間呢？答案是肯定的!這么做完全可以：那這不是違背了表屬于模式，而模式屬于數(shù)據(jù)庫(kù)，數(shù)據(jù)庫(kù)最終存在于指定表空間這個(gè)網(wǎng)的模型了嗎？！是的，看上去這確實(shí)是不合常理的，但這么做又是有它的道理的，而且現(xiàn)實(shí)中，我們往往需要這么做：將表的數(shù)據(jù)存在一個(gè)較慢的磁盤(pán)上的表空間，而將表的索引存在于一個(gè)快速的磁盤(pán)上的表空間。

但我們?cè)俨榭幢硭鶎俚哪Ｊ竭€是沒(méi)變的，它依然屬于指定的模式。所以這并不違反常理。實(shí)際上，PostgreSQL并沒(méi)有限制一張表必須屬于某個(gè)特定的表空間，我們之所以會(huì)這么認(rèn)為，是因?yàn)樵陉P(guān)系遞進(jìn)時(shí)，偷換了一個(gè)概念：模式是邏輯存在的，它不受表空間的限制。

關(guān)于PostgreSQL表空間、模式、表、用戶(hù)/角色之間的關(guān)系的相關(guān)知識(shí)就介紹到這里了，希望本次的介紹能夠?qū)δ兴斋@！

【編輯推薦】

1. SQL Server 2008 MDX學(xué)習(xí)筆記之理解元數(shù)組
2. SQL Server數(shù)據(jù)庫(kù)DataRelation的應(yīng)用示例詳解
3. SQL Server 2005/2008中的CTE應(yīng)用之遞歸查詢(xún)
4. SQL Server 2008數(shù)據(jù)庫(kù)學(xué)習(xí)筆記之MDX查詢(xún)示例
5. SQL Server 2008原生的分層數(shù)據(jù)類(lèi)型hierarchyid簡(jiǎn)介