本文都是關於一個最近最成功的開源產品，一個名叫PostgreSQL的關係數據庫。
數據庫開發商和開源開發者都是PostgreSQL的熱心擁護者。任何使用程序管理大量數據的人都可以從數據庫中獲得大量益處。PostgreSQL數據庫是一個非常優秀的關係數據庫實現，全功能，開源且免費使用。
PostgreSQL 數據庫支持大量的主流開發語言，包括C，C++，Perl，Python，Java，Tcl以及PHP。它是最接近工業標準SQL92的查詢語言，並且正在實現新的功能以兼容最新的SQL標準：SQL2003。PostgreSQL也獲得數個獎項，包括三次被評爲Linux Journal雜誌編輯選擇獎最佳數據庫(2000,2003和2004年度)以及2004年度Linux新媒體獎最佳數據庫系統。我們也許我們有點超越自我。你也許想知道到底PostgreSQL是什麼，爲什麼你要使用它。
本章我們將設置場景爲本書的剩餘部分並提供一些關於數據庫的概括性背景知識、不同類型的數據庫、爲什麼他們非常有用以及PostgreSQL在哪些地方符合這些要求。
基於數據編程
基本上所有的非普通計算機程序操作大量的數據，而且大量的應用程序被開發用來處理數據而不是進行計算任務。有些人估計當今世界上80%的應用程序開發會通過某種方式連接到數據庫中的複雜數據，所以數據庫對於很多應用來說是一種非常重要的基礎。
以數據編程的資源很豐富。大部分好的編程書籍都包含章節關於建立、存儲和操作數據。有三本書(由Wrox發佈)包含以數據編程的信息：
l 《Beginning Linux Programming》第三版覆蓋了DBM庫以及MySQL數據庫系統。
l 《Professional Linux Programming》包含關於PostgreSQL和MySQL數據庫系統的章節。
l 《Beginning Databases with MySQL》全面覆蓋了MySQL數據庫系統。
靜態數據
數據有很多形態和大小，我們根據數據的不同性質處理數據。有些情況下，數據非常簡單——也許僅僅是一個數字例如π的數值存在程序中用來畫圓。程序本身可能包含這個硬編碼的圓周率的值。我們把這種數據叫做靜態數據，它永遠不需要改變。
另一種靜態數據的例子是歐洲一些國家的匯率。在歐元區，貨幣都按固定的保留小數點後6位的精度兌換到歐元。假設我們開發一個歐元區貨幣轉換程序。他可能有一個硬編碼的貨幣名稱和基本匯率表，保存對應到歐元的兌換點數。這些匯率永遠不會改變。不過還沒完，因爲這張表會隨着歐元區國家數量的增長而增長。當一個國家註冊到歐元區，這個國家貨幣對歐元的匯率將被設定，它將需要被加入這張表中。當這種情況發生，匯率轉換程序需要修改，內置的貨幣表被修改，程序需要重建。這需要在每次貨幣表發生變化時做一次。
一個更好的辦法是應用程序讀取一個包含簡單的貨幣信息的文件，文件可能包含貨幣的名稱、國際符號以及匯率。之後在這個表需要改變時我們僅僅需要改變 這個文件，而不需要改變程序。
我們使用的這個數據文件沒有特別的結構;它僅僅包含幾行文本，包含一些數據讓應用程序讀取。它沒有固定的結構。因此我們把這種文件叫做扁平文件。以下是我們的貨幣文件可能的樣子：
France FRF 6.559570
Germany DEM 1.955830
Italy ITL 1936.270020
Belgium BEF 40.339901
用於數據存儲的扁平文件
扁平文件對於很多應用類型來說非常有用。由於文件保持在可管理大小，我們很容易改變它，扁平文件可能非常符合我們的需求。
很多系統和程序，特別是UNIX平臺，使用扁平文件存儲數據或者進行數據交換。UNIX的密碼文件就是一個例子，它通常情況下像以下的樣子：
neil:*:500:100:Neil Matthew:/home/neil:/bin/bash
nick:*:501:100:Rick Stones:/home/rick:/bin/bash
這個例子包含一系列的信息和屬性組成的記錄。文件被設計成每行包含一個記錄，整個文件則用來保存相關的記錄到一起。某些情形下，這種模式還不夠用，因而，我們需要增加擴展的功能來配合應用程序完成必須的工作。
重複單元和其他問題
假設我們決定擴展貨幣匯率程序(本章前面介紹過)來記錄每個國家的語言，以及人口和麪積。在扁平文件中，我們需要每行一個記錄，每個記錄由幾個熟悉構成。記錄中每個獨立的屬性總在固定的位置;例如貨幣符號總是第二個熟悉。所以我們可以認爲按列讀數據，每列總是相同類型的信息。
爲了添加某個國家使用的語言，我們可能會認爲我們只需爲每一行要添加一個新列。當我們發現一些國家有不止一種官方語言時，我們碰到了一個問題。所以，在我們給Belgium的記錄中，我們需要同時包含Flemish語和French語。對於Switzerland，我們需要添加四種語言。扁平文件在這是應該看起來像這樣：
France FRF 6.559570 French 60424213 547030
Germany DEM 1.955830 German 82424609 357021
Italy ITL 1936.270020 Italian 58057477 301230
Belgium BEF 40.339901 Flemish French 10348276 30528
Switzerland CHF 1.5255 German French Italian Romansch 7450867 41290
這個問題被稱爲重複單元。我們現在的問題是重複的數據項(語言)是在記錄內重複，也就是說數據可能會在列內重複，而不僅僅是記錄。扁平的文件無法應付這類問題，因爲它無法判斷什麼時候語言項列完了，開始下一個記錄了。解決這個問題唯一的方法是在文件內添加一些結構，但這種情況下這個文件不再是扁平文件了。
這裏有另一個示例。記錄DVD詳細信息的程序可能需要記錄生產的年份，導演，風格以及演員列表。我們可以設計一個和Windows的.ini文件格式差不多的文件，就像這樣：
[2001: A Space Odyssey]
year=1968
director=Stanley Kubrick
genre=science fiction
starring=Keir Dullea
starring=Leonard Rossiter
…
[Toy Story]
…
我們通過引入描述每個記錄類型的標記解決了重複單元的問題。但是，現在你的程序爲了獲得需要的數據，需要讀取和解析更復雜的文件。添加記錄以及搜索這種結構就更困難了。我們怎樣才能確保用於風格或分類的描述是從一個特定子集選擇的。我們怎樣才能很容易的搜索到Kubrick導演的電影?
由於對數據的需求越來越複雜，我們被迫寫越來越多的代碼用來讀取和存儲我們的數據。如果我們擴展我們的DVD管理程序，爲DVD出租店主包含一些有用的信息——例如會員信息，租金，退租信息和預定信息，在扁平文件中管理所有這些信息的希望渺茫。
另外一個通用問題就是大小的問題。雖然包含結構的文本文件可以通過暴力掃描回答複雜的查詢類似於“告訴我所有的最近三個月租過最少一次喜劇的會員”，不單代碼很難編寫，而且性能可能會很低。這是因爲程序除了掃描整個文件來查找任何一片信息外沒有別的辦法，即使是僅僅返回一條數據的問題“誰主演了2001年的A Space Odyssey”。
我們需要的是一種在通用數據處理系統裏用來存儲和檢索數據的方法，而不是總是發明一個個解決方案用於有點不同但非常相似的問題。
我們需要的是一個數據庫和一個數據庫管理系統。