PostgreSQL学习总结（6）—— PostgreSQL 模式（SCHEMA）详解

冷不防 2022-08-29 10:56 523阅读 0赞

# 前言 #

PostgreSQL 模式（SCHEMA）可以看着是一个表的集合。一个模式可以包含视图、索引、数据类型、函数和操作符等。相同的对象名称可以被用于不同的模式中而不会出现冲突，例如 schema1 和 myschema 都可以包含名为 mytable 的表。模式类似于操作系统层的目录，但是模式不能嵌套。一个PostgreSQL数据库集群包含一个或多个已命名数据库。用户和用户组在整个集群范围内是共享的，但是其它数据并不共享。任何与服务器连接的客户都只能访问那个在连接请求里声明的数据库。

**注意: 集群中的用户并不一定要有访问集群内所有数据库的权限。共享用户名的意思是不能有重名用户。假定同一个集群里有两个数据库和一个joe用户，系统可以配置成只允许joe 访问其中的一个数据库。**

一个数据库包含一个或多个已命名的模式，模式又包含表。模式还可以包含其它对象，包括数据类型、函数、操作符等。同一个对象名可以在不同的模式里使用而不会导致冲突；比如，schema1和myschema都可以包含一个名为mytable的表。和数据库不同，模式不是严格分离的：只要有权限，一个用户可以访问他所连接的数据库中的任意模式中的对象。

我们需要模式的原因有好多：

>  *  允许多个用户使用一个数据库而不会干扰其它用户。
>  *  把数据库对象组织成逻辑组，让它们更便于管理。
>  *  第三方的应用可以放在不同的模式中，这样它们就不会和其它对象的名字冲突。

模式类似于操作系统层次的目录，只不过模式不能嵌套。

# **一、 创建模式** #

要创建一个模式，使用CREATE SCHEMA命令。给出你选择的模式名字。比如：

CREATE SCHEMA myschema;

要创建或者访问在模式中的对象，写出一个受修饰的名字，这个名字包含模式名以及表名，它们之间用一个句点分开：

schema.table

这个方式在任何需要表名字的地方都可用，包括后面章节讨论的表修改命令和数据访问命令。出于简化，我们将只讨论表，这个概念适用于所有其它已命名对象类型，比如数据类型和函数。实际上，更一般的语法

database.schema.table

也可以使用，但目前它只是为了和 SQL 标准形式上兼容。如果你写了一个数据库名，那么它必须和你当前连接的数据库同名。要在新模式里创建一个表，用

CREATE TABLE myschema.mytable (
    ...
    );

如果一个模式是空的(所有它里面的对象都已经删除)，那么删除一个模式的命令如下：

DROP SCHEMA myschema;

要删除一个模式及其包含的所有对象，可以使用：

DROP SCHEMA myschema CASCADE;

通常你想创建一个他人拥有的模式(因为这是一种限制用户在定义良好的模式中的活动的方法)。其语法如下：

CREATE SCHEMA schemaname AUTHORIZATION username;

你甚至可以省略模式名字，这时模式名将和用户名同名。以pg\_开头的模式名是保留给系统使用的，用户不能创建这样的名字。

# **二、Public 模式** #

在前面的小节里，我们没有声明任何模式名字就创建了表。缺省时，这样的表(以及其它对象)都自动放到一个叫做"public"的模式中去了。每个新数据库都包含一个这样的模式。因此，下面的命令是等效的：

CREATE TABLE products ( ... );

和：

CREATE TABLE public.products ( ... );

# **三、模式搜索路径** #

全称的名字写起来非常费劲，并且我们最好不要在应用里直接写上特定的模式名。因此，表通常都是用未修饰的名字引用的，这样的名字里只有表名字。系统通过查找一个搜索路径来判断一个表究竟是哪个表，这个路径是一个需要查找的模式名列表。在搜索路径里找到的第一个表将被使用。如果在搜索路径中没有找到表，那么就报告一个错误(即使在数据库里的其它模式中存在此表也如此)。在搜索路径中的第一个模式叫做"当前模式"。除了是搜索的第一个模式之外，它还是在CREATE TABLE没有声明模式名的时候，新建表的默认所在地。要显示当前搜索路径，使用下面的命令：

SHOW search_path;

在缺省的设置中，返回下面的东西：

search_path
    --------------
    "$user",public

第一个元素声明搜索和当前用户同名的模式。因为还没有这样的模式存在，所以这条记录被忽略。第二个元素指向我们已经看过的公共模式。搜索路径中第一个存在的模式是创建新对象的缺省位置。这就是为什么缺省的对象都会创建在 public 模式里的原因。如果在其它环境中引用对象且没有模式修饰，那么系统会遍历搜索路径，直到找到一个匹配的对象。因此，在缺省的配置里，任何未修饰的访问只能引用 public 模式。要设置模式的搜索路径，可以用(省略了$user是因为并不立即需要它)

SET search_path TO myschema,public;

然后我们就可以不使用模式修饰来访问表了：

DROP TABLE mytable;

同样，因为myschema是路径中的第一个元素，新对象缺省时将创建在这里。我们也可以写成：

SET search_path TO myschema;

然后我们如果不明确修饰的话，就不能再访问 public 模式了。public 模式没有任何特殊之处，只不过它缺省时就存在。我们也可以删除它。搜索路径对于数据类型名、函数名、操作符名的运作方式和表名完全相同。数据类型和函数名可以像表名一样加以修饰。如果你需要在表达式里写一个有模式修饰的操作符，你必须这么写：

OPERATOR(schema.operator)

这样是为了避免语法歧义。下面是一个例子：

SELECT 3 OPERATOR(pg_catalog.+) 4;

实践中我们通常依赖搜索路径寻找操作符，这样就不用写这么难看的东西了。

# **四、模式和权限** #

缺省时，用户无法访问模式中不属于他们所有的对象。为了让他们能够访问，模式的所有者需要在模式上赋予他们USAGE权限。为了让用户使用模式中的对象，我们可能需要赋予适合该对象的额外权限。

用户也可以在别人的模式里创建对象。要允许这么做，需要被赋予在该模式上的CREATE权限。请注意，缺省时每个人都在public模式上有CREATE和USAGE权限。这样就允许所有可以连接到指定数据库上的用户在这里创建对象。如果你不打算这么做，可以撤销这个权限：

REVOKE CREATE ON SCHEMA public FROM PUBLIC;

第一个"public"是模式，第二个"public"意思是"所有用户"。第一句里它是个标识符，而第二句里是个关键字，所以有不同的大小写。

# **五、系统表模式** #

除了public和用户创建的模式之外，每个数据库都包含一个pg\_catalog模式，它包含系统表和所有内置数据类型、函数、操作符。pg\_catalog总是搜索路径中的一部分。如果它没有明确出现在路径中，那么它隐含地在所有路径之前搜索。这样就保证了内置名字总是可以被搜索。不过，你可以明确地把pg\_catalog放在搜索路径之后，如果你想使用用户自定义的名字覆盖内置的名字的话。

自从系统表名以pg\_开头开始，最好避免使用这样的名字，以保证自己将来不会和新版本冲突：那些版本也许会定义一些和你的表同名的表(在缺省搜索路径中，一个对你的表的无修饰引用将解析为系统表)。系统表将继续遵循以pg\_开头的传统，因此，只要你的表不是以pg\_开头，就不会和无修饰的用户表名字冲突。

# **六、使用方式** #

模式可以用多种方式组织数据。下面是一些建议使用的模式，它们也很容易在缺省配置中得到支持：

如果没有创建任何模式，那么所有用户隐含都访问 public 模式。这样就模拟了没有模式的时候的情景。这种设置建议主要用在只有一个用户或者数据库里只有几个可信用户的情形。这样的设置也允许我们平滑地从无模式的环境过渡。

你可以为每个用户创建一个模式，名字和用户相同。要记得缺省的搜索路径从$user开始，它会解析为用户名。因此，如果每个用户都有一个独立的模式，那么他们缺省时访问他们自己的模式。如果你使用了这样的设置，那么你可能还想撤销对 public 模式的访问(或者删除它)，这样，用户就真的限制于他们自己的模式了。

要安装共享的应用(被所有人使用的表、第三方提供的额外函数等等)，我们可以把它们放到独立的模式中。只要记得给需要访问它们的用户赋予合适的权限就可以了。然后用户就可以通过用一个模式名修饰来使用这些额外的对象，或者他们可以把额外的模式放到他们的搜索路径中。

# **七、移植性** #

在 SQL 标准里，在同一个模式里的对象被不同的用户所有的概念是不存在的。而且，有些实现不允许你创建和它们的所有者不同名的模式。实际上，模式的概念和用户在那些只实现了标准中规定的基本模式支持的数据库系统里几乎是一样的。因此，许多用户考虑对名字加以修饰，使它们真正由username.tablename 组成。如果你为每个用户都创建了一个模式，这实际上就是PostgreSQL的行为。

同样，在 SQL 标准里也没有public模式的概念。为了最大限度地遵循标准，你不应该使用(可能甚至是应该删除)public模式。当然，有些数据库系统可能根本没有模式，或者是通过允许跨数据库访问来提供模式的功能。如果你需要在这些系统上干活，那么为了最大限度的移植性，应该根本不使用模式。