第二章关系数据库原理
在本章中，我们将研究什么会组成一个数据库系统，特别是PostgreSQL这样的现实世界中非常有用的关系数据库系统。我们将从电子表格开始，它和关系数据库有很多相同的地方，同时也有重大的局限性。我们将学习像PostgreSQL一样的关系数据库怎么拥有比电子表格强悍的很多功能。顺带，我们将继续我们的非正式的对SQL的研究。
特别是，本章将讨论以下主题：
l 电子表格：它们的问题和局限
l 数据库怎样存储数据
l 怎样访问数据库中的数据
l 基本的数据库设计，用到多个表格
l 表之间的关系
l 一些基本数据类型
l NULL值，用来表示一个未知的值
电子表格的局限性
电子表格软件，例如Microsoft Excel，被广泛应用于数据存储和查阅。它很容易用不同的方法排序数据，并通过眼睛直接观察数据的内容和模式。
不幸的是，人们经常误解一个很好的用于查看和操作数据的工具为一个存储和共享复杂的甚至是关键业务数据的工具。这两种需求通常相差甚远。
很多人都熟悉一种或多种电子表格软件，并能够按照一定的行列的规则组织一些数据。图2-1显示了一个示例——一个保存客户数据的OpenOffice（http://www.openoffice.org/）电子表格。
图2-1 简单的电子表格
当然，这样的信息容易被看到和修改。每个客户有单独的一行，而且客户的每段信息保存在一个单独的列中，就像图2-2中列出来的一样。一列和行的交集是一个单元格。
图2-2 一些电子表格的术语
这个简单的电子表格包含需要在我们开始设计数据库时顺手记下的几个功能。例如，姓和名分别在不同的列，这使按性和名排序的时候更容易。
所以，在电子表格里头保存客户信息有什么错？电子表格很好，因为你：
l 没有太多客户
l 每个客户没有太多的复杂细节
l 不需要保存任何其他的重复信息，例如若干客户的订单
l 不需要很多人同时更新信息
l 可以确保保存重要信息的电子表格定期得到备份
电子表格式一个了不起的主意，而且是一个可以解决很多类型问题的很好的工具。但是，就像你不会（或者至少不应该）尝试用牛刀杀鸡一样，有些时候电子表格你完成工具的恰当工具。
试想如果在一个有用成千上万客户的大公司将所有的客户信息保存在一张电子表格的主副本中将会怎样。在一个大公司，很可能很多人需要更新这个列表。虽然文件锁可以确保同一时间只有一个人可以修改这个列表，随着需要修改这个文件的人数的增多，他们需要花费更长的时间等待轮到自己修改这个列表。我们所想要的是让许多人同时读取，更新，添加和删除行，并让计算机确保没有冲突。显然，简单的文件锁定将不足以有效地处理这个问题。
电子表格的另一个问题是它们是绝对的二维的。假设我们还要存储每个客户的订单的细节。刚开始我们可以将订单细节紧贴着客户信息存放。当随着每个客户订单信息的增长，电子表格会变得越来越复杂。考虑到这样的结果，我们开始为每个客户添加一些基本订单信息，如图2-3所示。
图2-3 保存有多条订单信息的电子表格
不幸的是，它看上去不在那么优雅了。我们现在又变长的行，且没有容易的方法计算么个客户会占用多少。甚至，我们会达到每条记录允许的最大的列数。这就是我们在前面章节碰到的重复组的问题。在电子表格中的多表格会有点帮助，但他们不是解决这个问题的理想方法。
电子表格受到的挑战
这是一个你怎样很容易超过电子表格限制的例子。一个熟人正尝试建立一个电子表格用来帮做小型生意的朋友存储信息。这个生意需要记录皮革项目，每个项目的价格不单依赖于生产它所需要的时间和劳动，同时还依赖于制造过程中所耗费的皮革的单位成本。物主需要购买不同批次的皮革，每个批次需的单价依赖于皮革的档次和购买时间。然后他们需要在他们制造皮革制品的时候在库存中使用先进先出的策略，通常皮革是按批购买的。我们的挑战是建立一个电子表格完成以下功能：
l 跟踪当前的库存价格
l 跟踪有多少批次不同级别的皮革在仓库中
l 跟踪当前被使用在生产某个项目上的批次和级别的皮革已经支付了多少钱
经过几天的努力，他们发现这种表面上简单的仓储管理需求出人意料的难以转换到一个电子表格。仓储记录多变的特征不适合电子表格的理念。
在这里我们想指出的是电子表格有其合适的位置，但也有其使用的限制。
原创文章，转载请注明： 文章地址PostgreSQL从菜鸟到专家 第二章关系数据库原理
版权声明：本文内容由互联网用户自发贡献，该文观点与技术仅代表作者本人。本站仅提供信息存储空间服务，不拥有所有权，不承担相关法律责任。如发现本站有涉嫌侵权/违法违规的内容， 请发送邮件至 dio@foxmail.com 举报，一经查实，本站将立刻删除。