PostgreSQL 7.3的中文文档。高级特性

黄叶

PostgreSQL 7.3 文档
Prev                Next
Chapter 3. 高级特性

Table of Contents
3.1. 介绍
3.2. 视图
3.3. 外键
3.4. 事务
3.5. 继承
3.6. 结论

3.1. 介绍

在前面几章里，我们介绍了使用 SQL 存储和 访问在 PostgreSQL 里的数据的基本方法． 我们现在将讨论一些 SQL 更高级的特性，这些特性 可以简化管理和避免你的数据的丢失或损坏．最后，我们将看看一些 PostgreSQL 的扩展．

本章将不时引用在 Chapter 2 里的例子，并且 对它们进行修改和提高，因此如果你已经看过那章会更好． 本章的一些例子也可以在教程目录里的advanced.sql 文件里找到．这个文件还包括一些要装载的例子数据，这些数据没有在这里 介绍．(请参考 Section 2.1 获取如何使用该文件 的方法．)
Prev        Home        Next
删除        Up        视图

PostgreSQL 7.3 文档
Prev        Chapter 3. 高级特性        Next
3.2. 视图

回头看看在 Section 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 数据库的一个关键要素． 视图允许我们把表的细节封装起来，这些表可能因你的应用的变化而变化， 但是我们却可以通过视图给用户一个一致的接口．

视图几乎可以在一个真正的表可以使用的任何地方使用． 在其它视图上面再建造视图也是很常见的．
Prev        Home        Next
高级特性        Up        外键


PostgreSQL 7.3 文档
Prev        Chapter 3. 高级特性        Next
3.3. 外键

回忆一下 Chapter 2 里的 weather 和 cities 表．考虑一下下面的问题∶你想确保没有人可以在 weather 表里插入一条在 cities 表里没有匹配记录的记录． 这就叫维护你的表的参考完整性． 在简单的数据库系统里，实现(如果也叫实现)这个特性的方法 通常是先看看 cities 表里是否有匹配的记录， 然后插入或者拒绝新的 weather 记录． 这个方法有许多问题，而且非常不便，因此 PostgreSQL 可以为你做这些．

新的表声明看起来会象下面这样∶

CREATE TABLE cities (
        city            varchar(80) primary key,
        location        point
);

CREATE TABLE weather (
        city            varchar(80) references cities,
        temp_lo         int,
        temp_hi         int,
        prcp            real,
        date            date
);

然后我们试图插入一条非法的记录∶

INSERT INTO weather VALUES ('Berkeley', 45, 53, 0.0, '1994-11-28');

ERROR:  <unnamed> referential integrity violation - key referenced from weather not found in cities

外键的行为可以为你的应用仔细调节．在这份教程里我们就不再 多说了，而是请你参考PostgreSQL 7.3 用户手册获取更多的信息． 正确使用外键无疑将改进你的数据库应用，所以我们强烈建议你学习它们．
Prev        Home        Next
视图        Up        事务


PostgreSQL 7.3 文档
Prev        Chapter 3. 高级特性        Next
3.4. 事务

事务是所有数据库系统的一个基本概念． 一次事务的要点就是它把多个步骤捆绑成了一个单一的，不成功则成仁的操作． 其它并行的事务是看不到在这些步骤之间的中间状态的，并且如果发生了一些 问题，导致该事务无法完成，那么所有这些步骤都完全不会影响数据库．

比如，假设一个银行的数据库包含各种客户帐户的余额，以及每个分行的 总余额．假设我们要记录一次从 Alice 的帐户到 Bob 的帐户的金额为 $100.00 的支付动作．那么，完成这个任务的简单到极点的 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 块不是 Alice 支付的钱，也不希望 Alice 老是不花钱从 Bob 那里拿到物品．我们需要保证∶如果在操作的过程中出了差错， 那么所有这些步骤都不会发生效果．把这些更新组合成一个 事务就给予我们这样的保证． 事务被认为是原子的∶从其它事务的角度来看， 它要么是全部发生，要么完全不发生．

我们还需要保证∶一旦一个事务完成并且得到数据库系统的认可， 那么它必须被真正永久地存储，并且不会在随后的崩溃中消失． 比如，如果我们记录到了一个 Bob 撤单的动作，那么我们不希望 仅仅在他走出银行大门之后的一次崩溃就会导致对他的帐户的 扣减动作消失．一个事务型数据库保证一个事务所做的所有更新 在事务发出完成响应之前都记录到永久的存储中(也就是磁盘)．

事务型数据库的另外一个重要的性质和原子更新关系密切∶ 当多个事务并行地运行的时候，那么每个事务都不应看到其它事务 所做的未完成的变化．比如，如果一个事务正忙着计算所有分行的 余额总和，那么它不应该包括来自 Alice 的分行的扣帐和来自 Bob 分行的入帐，反之亦然．所以事务必须是黑白分明的，不仅仅体现在它们 在数据库上产生的永久影响出发，而且体现在它们运转时的自身的可视性上． 一个打开的事务做的更新在它完成之前是其它事务无法看到的，而且所有更新 是同时可见的．

在 PostgreSQL 里，一个事务是通过把SQL 命令用 BEGIN 和 COMMIT 命令包围实现的． 因此我们的银行事务实际上看起来象下面这样

BEGIN;
UPDATE accounts SET balance = balance - 100.00
    WHERE name = 'Alice';
-- 等等
COMMIT;

如果在该事务的过程中，我们决定不做提交(可能是我们刚发现 Alice 的 余额是负数)，那么我们可以发出 ROLLBACK 命令而不是 COMMIT 命令，那么到目前为止我们的所有更新都会被取消．

PostgreSQL 实际上把每个 SQL 语句当做在一个事务中 执行的来看待．如果你没有发出 BEGIN 命令，那么每个独立 的语句都有一个隐含的 BEGIN 和(如果成功的话) COMMIT 语句包围在周围．一组包围在 BEGIN 和 COMMIT 语句中间的语句有时候被称做事务块．

    注意: 一些客户库自动发出 BEGIN 和 COMMIT， 因此你可能不需要特意请求就可以获取事务块的效果．查看你使用的 接口的文档．

Prev        Home        Next
外键        Up        继承


PostgreSQL 7.3 文档
Prev        Chapter 3. 高级特性        Next
3.5. 继承

继承是面向对象的数据库的概念．它开启了数据库设计新的可能性大门．

让我们创建两个表∶一个表 cities 和一个表 capitals．自然，首府(capital)也可以是 城市(cities)，因此在列出所有城市时你想要某种方法隐含地显示首府． 如果你已经很高明了，那么你可能会创造类似下面这样的大纲∶

CREATE TABLE capitals (
    name            text,
    population      real,
    altitude        int,    -- (单位是英尺)
    state           char(2)
);

CREATE TABLE non_capitals (
    name            text,
    population      real,
    altitude        int     -- (单位是英尺)
);

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     -- (单位是英尺)
);

CREATE TABLE capitals (
    state           char(2)
) INHERITS (cities);

在这个例子里，capitals 的一行 继承所有来自它的父表， cities的所有字段(name， population，和altitude)． 字段 name 的类型是 text， 是 PostgreSQL 用于变长字符串的固有类型． 州首府有一个额外的字段，州，显示所处的州．在 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 表示法．
Prev        Home        Next
事务        Up        结论

黄叶

PostgreSQL 7.3 文档
Prev        Chapter 3. 高级特性        Next
3.6. 结论

PostgreSQL 有许多这份教程里没有谈到 的特性，因为这份教程主要是面向新 SQL 用户的． 这些特性在PostgreSQL 7.3 用户手册和 PostgreSQL 7.3 程序员手册里有更充分的介绍．

如果你觉得自己需要更多介绍性材料，请访问 PostgreSQL网站 获取更多资源的联接．
Prev        Home        Next
继承        Up        PostgreSQL 7.3 用户手册

ftyh

终于看到有人也建议学习POSTGRESQL了，我本来还想放弃的说。
现在有点勇气了。

有点建议。就是你其实应该将这些内容做成一个索引，这样大家看起来也方便，不用在版里一直找。你说是吧。
  还有这个好像在laser.zhengmai.com.cn网站里面有吧，但是没有提供下载包。只能一页一页的看。

黄叶

谢谢老兄。
希望老兄以后多来这个版面指导呀。
本版人气太冷清了。