上一章我们描述了PostgreSQL中使用SQL存储和访问数据的基本概念。接下来我们将会讨论一些简化管理和防止数据丢失或损坏的高级特性。最后,我们将会了解一些PostgreSQL扩展。
本章将会引用第2章中的一些示例,并且进行修改和改进,所以最好先阅读第2章。本章的某些示例也可以在tutorial目录中的advanced.sql中找到。该文件中还包含一些示例数据。
回顾2.6节中的查询。假设你的应用特别关注天气记录和城市位置的组合信息,但是你不想每次都输入相同的查询。你可以基于该查询创建一个视图,视图给查询指定了一个名称,你可以像使用普通表一样引用该视图。
CREATE VIEW myview AS
SELECT city, temp_lo, temp_hi, prcp, date, location
FROM weather, cities
WHERE city = name;
SELECT * FROM myview;
充分利用视图是一个好的SQL数据库设计的关键之一。视图可以封装表的结构细节,随着应用的改进,表的结构可能会发生变化,而对外的接口是一致的。
视图可以用在几乎所有可以使用真实表的地方。视图也可以基于其他视图创建。
回想一下第2章中的weather表和cities表。考虑以下问题:你想要确保如果在cities表中没有匹配的行时,不能在weather表中插入数据行。这种操作被称为维护数据的参照完整性。在过于简单化的数据库系统中,可能采用这种实现方式(如果存在的话):首先查看cities表,检查是否存在匹配的记录,然后插入或者拒绝新的天气记录。这种方法存在许多问题,而且很麻烦,因此PostgreSQL可以帮助你完成这些操作。
新版的表定义如下:
CREATE TABLE cities (
city varchar(80) primary key,
location point
);
CREATE TABLE weather (
city varchar(80) references cities(city),
temp_lo int,
temp_hi int,
prcp real,
date date
);
然后尝试插入一个无效的记录:
INSERT INTO weather VALUES ('Berkeley', 45, 53, 0.0, '1994-11-28');
ERROR: insert or update on table "weather" violates foreign key constraint "weather_city_fkey"
DETAIL: Key (city)=(Berkeley) is not present in table "cities".
外键的行为可以针对应用进行精细的调整。本教程不设计更复杂的示例,但是更多信息可以参考第5章。正确使用外键将会明确地改善数据库应用的性能。
事务是所有数据库系统中的一个基本概念。事务的本质在于它将多个步骤捆绑成一个单一的操作,这些步骤要么全部成功,要么全部失败。多步操作的中间状态对于其他并发的事务是不可见的,并且如果由于某些失败导致事务无法完成,所有的操作都不会成功,不会对数据库产生任何影响。
例如,考虑一个银行数据库,其中包含了各种客户账户的余额,以及各个分行的总存款余额。假设我们要记录一次支付,从Alice的账户转移100.00美元到Bob的账户。简单地说,执行该操作的SQL命令类似如下:
UPDATE accounts SET balance = balance - 100.00
WHERE name = 'Alice';
UPDATE branches SET balance = balance - 100.00
WHERE name = (SELECT branch_name FROM accounts WHERE name = 'Alice');
UPDATE accounts SET balance = balance + 100.00
WHERE name = 'Bob';
UPDATE branches SET balance = balance + 100.00
WHERE name = (SELECT branch_name FROM accounts WHERE name = 'Bob');
以上命令的细节暂时不重要;重要的是使用了几个单独的更新语句来完成这个相当简单的操作。银行主管想要确保的是这些更新全部都成功,或者全部都不执行。显然不希望系统失败时会导致Bob收到了100.00美元,而Alice没有扣除100.00美元。同样Alice也不希望她被扣了款,而Bob没有收到付款。我们需要保证如果操作过程中出现错误,以及执行的任何步骤都不会生效。将这些更新组合成一个事务可以提供这种保证。事务的原子性在于:对于其他事务,事务中的操作要么全部发生,或者全部失败。
我们还需要保证一旦事务完成并且得到数据库系统的确认,事务将被永久记录,并且不会因随后的故障而导致丢失。例如,假设我们记录了一笔Bob的提现操作,我们不希望在他刚刚走出银行大门之后,他的账户扣款记录就因系统故障而丢失。事务型数据库能够确保一个事务的所有更新在事务响应成功之前都被记录到永久存储中(例如磁盘)。
事务型数据库另一个重要的属性与原子更新的概念密切相关:当多个事务并发执行的时候,事务之间不能看到其他事务未完成的修改。例如,加入一个事务正在计算各个分行余额的总和,它不会包含Alice所在分行的扣款而不包含Bob所在分行的存款,或者相反。因此,事务的全有或者全无不仅仅是体现在对数据库的永久影响,而且体现在它们发生时的可见性上。一个事务的所有更新对于其他事务是不可见的,直到事务完成,因此所有更新对于其他事务都是同时可见的。
在PostgreSQL中,事务的创建是通过将SQL命令包围在BEGIN命令和COMMIT命令之间来实现的。因此,以上的银行事务实际上类似如下:
BEGIN;
UPDATE accounts SET balance = balance - 100.00
WHERE name = 'Alice';
-- etc etc
COMMIT;
如果在事务的过程中,我们决定不提交(可能因为我们注意到Alice的余额不足),我们可以提交ROLLBACK命令而不是COMMIT,而到目前为止所有的更新都将被撤销。
实际上PostgreSQL认为每一条SQL语句都是在事务中执行。如果没有提交BEGIN命令,那么每条单独的语句都将被一条隐式的BEGIN和COMMIT(如果成功的话)包围。BEGIN和COMMIT包围的一组语句有时被称作一个事务块。
注意:有些客户端程序库自动提交BEGIN和COMMIT命令,因此你不需要明确要求就能获得事务块的效果。
使用保存点可以对事务中的语句执行更细粒度的控制。保存点允许你选择性放弃事务一部分操作,同时提交剩余的部分。在使用SAVEPOINT定义保存点之后,在需要的时候可以使用ROLLBACK TO回滚到保存点。保存点到回滚操作之间的所有数据库变更都将被丢弃,但是保存点之前的变更将被保留。
在回滚到某个保存点之后,该保存点仍然存在,因此可以多次回滚到该保存点。相反,如果你确定不再需要回滚到某个保存点,可以释放它,以便系统能够释放一些资源。注意,释放或者回滚到某个保存点将会自动释放该保存点之后所有的保存点。
所有事情都发生在事务块的内部,因此对于其他数据库会话都是不可见的。当你提交事务块之后,所有提交的操作作为一个整体对其他事务可见,而回滚的操作绝不会对其他事务可见。
回到银行数据库,假设我们从Alice的账户中扣除100.00美元,并且存入Bob的账户,随后才发现实际应该存入Wally的账户。我们可以使用保存点解决这个问题:
BEGIN;
UPDATE accounts SET balance = balance - 100.00
WHERE name = 'Alice';
SAVEPOINT my_savepoint;
UPDATE accounts SET balance = balance + 100.00
WHERE name = 'Bob';
-- oops ... forget that and use Wally's account
ROLLBACK TO my_savepoint;
UPDATE accounts SET balance = balance + 100.00
WHERE name = 'Wally';
COMMIT;
这个例子的确有点过于简单,但是通过在事务块中使用保存点可以进行各种控制。而且,当事务由于错误而中断时,ROLLBACK TO是重新获取事务控制的唯一方法,除了回滚整个事务并重新开始之外。
窗口函数基于与当前行相关的一组行执行一个计算。这相当于聚合函数的计算。但是与常规的聚合函数不同,使用窗口函数不会将多行组合成单一的结果行--每一行都有单独的输出。在后台计算中,窗口函数除了查询结果的当前行之外,还能访问其他的行。
下例演示了如何比较每个雇员的薪水和他/她所在部门的平均薪水:
SELECT depname, empno, salary, avg(salary) OVER (PARTITION BY depname) FROM empsalary;
depname | empno | salary | avg
-----------+-------+--------+-----------------------
develop | 11 | 5200 | 5020.0000000000000000
develop | 7 | 4200 | 5020.0000000000000000
develop | 9 | 4500 | 5020.0000000000000000
develop | 8 | 6000 | 5020.0000000000000000
develop | 10 | 5200 | 5020.0000000000000000
personnel | 5 | 3500 | 3700.0000000000000000
personnel | 2 | 3900 | 3700.0000000000000000
sales | 3 | 4800 | 4866.6666666666666667
sales | 1 | 5000 | 4866.6666666666666667
sales | 4 | 4800 | 4866.6666666666666667
(10 rows)
前3列输出直接来自表empsalary,该表中的每一行数据显示一行输出。第2列代表了与当前行的depname值相同的所有行的平均值。(这个函数实际上和常规的avg聚合函数是同一个,但是OVER子句导致它成为一个窗口函数,并且基于一组相应的行进行计算。)
窗口函数调用总是包含一个OVER子句,直接写在窗口函数和名称和参数之后。这是它与常规函数和聚合函数语法的区别。OVER子句决定了如何拆分查询的行,以便窗口函数进行处理。OVER中的PARTITION BY列表将满足PARTITION BY表达式值相同的行分成一组,或者分区。对于每一行,窗口函数基于与当前行位于相同分区的行进行计算。
你还可以使用OVER中的ORDER BY控制窗口函数处理的行的顺序。(窗口的ORDER BY不需要匹配行输出时的顺序。)例如:
SELECT depname, empno, salary,
rank() OVER (PARTITION BY depname ORDER BY salary DESC)
FROM empsalary;
depname | empno | salary | rank
-----------+-------+--------+------
develop | 8 | 6000 | 1
develop | 10 | 5200 | 2
develop | 11 | 5200 | 2
develop | 9 | 4500 | 4
develop | 7 | 4200 | 5
personnel | 2 | 3900 | 1
personnel | 5 | 3500 | 2
sales | 1 | 5000 | 1
sales | 4 | 4800 | 2
sales | 3 | 4800 | 2
(10 rows)
如上,rank函数按照ORDER BY子句的顺序,为当前行所在分区内的每个不同的ORDER BY值生成一个数字的排名。rank不需要显式的参数,因为它的行为完全取决于OVER子句。
窗口函数的输入行来自由查询的FROM子句经过WHERE、GROUP BY和HAVING子句过滤之后产生的“虚拟表”。例如,由于不满足WHERE条件而被剔除的行不会被任何窗口函数使用。一个查询可以包含多个窗口函数,它们通过不同的OVER子句对数据进行不同的切分,但是它们都基于虚拟表的相同的行集。
我们已经知道,如果行的顺序不重要,可以忽略ORDER BY。此外,还可以忽略PARTITION BY,这样的话,所有的行被分为一个分区。
窗口函数还有另外一个重要的概念:对于每一行,在它的分区内存在一组行,被称为窗口框架。许多(但并非全部)窗口函数只基于窗口框架,而不是整个分区,进行计算。默认情况下,如果存在ORDER BY,窗口框架包括分区的起始行直到当前行,以及根据ORDER BY条件等于当前行的其他行。如果不存在ORDER BY,默认的窗口框架包含分区的所有行。窗口框架还有其他的定义方式,更多细节参考第4.2.8节。以下是一个使用sum的示例:
SELECT salary, sum(salary) OVER () FROM empsalary;
salary | sum
--------+-------
5200 | 47100
5000 | 47100
3500 | 47100
4800 | 47100
3900 | 47100
4200 | 47100
4500 | 47100
4800 | 47100
6000 | 47100
5200 | 47100
(10 rows)
上例中,由于OVER子句中没有ORDER BY,窗口框架与分区相同,又因为没有PARTITION BY,窗口框架等价与整个表;也就是说,每个sum基于整个表进行计算,因此每一行的sum结果都一样。但是如果添加一个ORDER BY子句,结果将会不同:
SELECT salary, sum(salary) OVER (ORDER BY salary) FROM empsalary;
salary | sum
--------+-------
3500 | 3500
3900 | 7400
4200 | 11600
4500 | 16100
4800 | 25700
4800 | 25700
5000 | 30700
5200 | 41100
5200 | 41100
6000 | 47100
(10 rows)
此时,sum基于第一个薪水值(最低的值)到当前值计算,包括与当前值相同的重复值(注意重复薪水值的结果)。
窗口函数只能用于查询的SELECT列表和ORDER BY子句。其他的地方不能使用窗口函数,例如GROUP BY、HAVING以及WHERE子句。这是因为窗口函数逻辑上是在这些子句之后进行的计算。此外,窗口函数在常规聚合函数之后执行。这意味着可以在窗口函数的参数中使用聚合函数,但是反过来不行。
如果需要在窗口函数执行之后进行过滤和分组,可以使用子查询。例如:
SELECT depname, empno, salary, enroll_date
FROM
(SELECT depname, empno, salary, enroll_date,
rank() OVER (PARTITION BY depname ORDER BY salary DESC, empno) AS pos
FROM empsalary
) AS ss
WHERE pos < 3;
以上查询只显示内部查询中排名小于3的行。
当一个查询使用了多个窗口函数时,可以为每个窗口函数编写一个单独的OVER子句,但是如果多个窗口函数拥有相同的窗口行为,这种写法即重复又容易出错。相反,每个窗口行为可以在一个WINDOW子句中进行命名,然后在OVER中进行引用。例如:
SELECT sum(salary) OVER w, avg(salary) OVER w
FROM empsalary
WINDOW w AS (PARTITION BY depname ORDER BY salary DESC);
关于窗口函数的更多信息,可以参考第4.2.8节、9.21节、7.2.4节以及SELECT参考页。
继承是面向对象数据库的一个概念。它为数据库设计带来了一些有趣的新特性。
创建两个表:cities和capitals。首都当然也是城市,所以当你列出所有城市时,你也想要能够隐式地显示首都。聪明的你可能会想出类似以下的方案:
CREATE TABLE capitals (
name text,
population real,
altitude int, -- (in ft)
state char(2)
);
CREATE TABLE non_capitals (
name text,
population real,
altitude int -- (in ft)
);
CREATE VIEW cities AS
SELECT name, population, altitude FROM capitals
UNION
SELECT name, population, altitude FROM non_capitals;
这对于查询没有问题,但是如果需要更新其中某些行时,这种方案无能为力。
一个更好的方案如下:
CREATE TABLE cities (
name text,
population real,
altitude int -- (in ft)
);
CREATE TABLE capitals (
state char(2)
) INHERITS (cities);
这种情况下,capitals中的行继承了它的父表cities中的所有列(name、population以及altitude)。name列的类型是text,它是用于变长字符串的一个PostgreSQL原生类型。州的首府包含一个额外的列,state,表示首府所在的州。在PostgreSQL中,一个表可以继承零个或者多个其他的表。
举例说明,以下查询显示所有维度大于500英尺的城市,包括首府:
SELECT name, altitude
FROM cities
WHERE altitude > 500;
结果如下:
name | altitude
-----------+----------
Las Vegas | 2174
Mariposa | 1953
Madison | 845
(3 rows)
另一方面,以下查询显示所有维度大于500英尺,并且不是首府的城市:
SELECT name, altitude
FROM ONLY cities
WHERE altitude > 500;
name | altitude
-----------+----------
Las Vegas | 2174
Mariposa | 1953
(2 rows)
其中,cities前面的ONLY表示只查询cities表,而不包含继承层级中低于cities的表。许多我们已经讨论过的命令--SELECT、UPDATE和DELETE--都支持ONLY用法。
注意:虽然继承通常很有用,但是它还不能和唯一约束或者外键一起使用,这限制了它的有用性。更多信息参考第5.8节。
PostgreSQL的许多特性在本教程中没有涉及,本教程主要面向SQL的新用户。这些特性将在本书的剩余部分进行详细讨论。
如果需要更多介绍资料,可以访问www.postgresql.org。