PostGRESql

PostgreSQL is finding an eager audience among
database aficionados and open-source developers alike. Anyone who is creating an application
with nontrivial amounts of data can benefit from using a database. PostgreSQL is an excellent
implementation of a relational database, fully featured, open source, and free to use.
PostgreSQL can be used from just about any major programming language you care to
name, including C, C++, Perl, Python, Java, Tcl, and PHP. It very closely follows the industry
standard for query languages, SQL92, and is currently implementing features to increase
compliance with the latest version of this standard, SQL:2003. PostgreSQL has also won several
awards, including the Linux Journal Editor’s Choice Award for Best Database three times (for
the years 2000, 2003, and 2004) and the 2004 Linux New Media Award for Best Database System.
We are perhaps getting a little ahead of ourselves here. You may be wondering what exactly
PostgreSQL is, and why you might want to use it.



Programming with Data


Nearly all nontrivial computer applications manipulate large amounts of data, and a lot of
applications are written primarily to deal with data rather than perform calculations. Some
writers estimate that 80% of all application development in the world today is connected in
some way to complex data stored in a database, so databases are a very important foundation
to many applications.
Resources for programming with data abound. Most good programming books will
contain chapters on creating, storing, and manipulating data. Three of our previous books
(published by Wrox Press) contain information about programming with data:


Constant Data
Data comes in all shapes and sizes, and the ways that we deal with it will vary according to the
nature of the data. In some cases, the data is simple—perhaps a single number such as the
value of π that might be built into a program that draws circles. The application itself may have
this as a hard-coded value for the ratio of the circumference of a circle to its diameter. We call
this kind of data constant, as it will never need to change.
Another example of constant data is the exchange rates used for the currencies of some European
countries. In so-called “Euro Land,” the countries that are participating in the single
European currency (euro) fixed the exchange rates between their national currencies to six
decimal places. Suppose we developed a Euro Land currency converter application. It could
have a hard-coded table of currency names and base exchange rates, the numbers of national
units to the euro. These rates will never change. We are not quite finished though, as it is
possible for this table of currencies to grow. As countries sign up for the euro, their national
currency exchange rate is fixed, and they will need to be added to the table. When that
happens, the currency converter needs to be changed, its built-in table changed, and the
application rebuilt. This will need to be done every time the currency table changes.
A better method would be to have the application read a file containing some simple
currency data, perhaps including the name of the currency, its international symbol, and
exchange rate. Then we can just alter the file when the table needs to change, and leave the
application alone.
The data file that we use has no special structure; it’s just some lines of text that mean
something to the particular application that reads it. It has no inherent structure. Therefore we
call it a flat file. Here’s what our currency file might look like:
France FRF 6.559570
Germany DEM 1.955830
Italy ITL 1936.270020
Belgium BEF 40.339901



Flat Files for Data Storage


Flat files are extremely useful for many application types. As long as the size of the file remains
manageable, so that we can easily make changes, a flat file scheme may be sufficient for our
needs.
Many systems and applications, particularly on UNIX platforms, use flat files for their data
storage or data interchange. An example is the UNIX password file, which typically has lines
that look like this:
neil:*:500:100:Neil Matthew:/home/neil:/bin/bash
nick:*:501:100:Rick Stones:/home/rick:/bin/bash
These examples consist of a number of elements of information, or attributes, together
making up a record. The file is arranged so that each line represents a single record, and the
whole file acts to keep the related records together. Sometimes this scheme is not quite good
enough, however, and we need to add extra features to support the job the application must do.



What Is a Database Management System?
The Merriam-Webster online dictionary (http://www.merriam-webster.com) defines a database
as a usually large collection of data organized especially for rapid search and retrieval (as by
a computer).
A database management system (DBMS) is usually a suite of libraries, applications, and
utilities that relieve an application developer from the burden of worrying about the details of
storing and managing data. It also provides facilities for searching and updating records. DBMSs
come in a number of flavors developed over the years to solve particular kinds of data-storage
problems.


Database Models
During the 1960s and 1970s, developers created databases that solved the repeating groups
problem in several different ways. These methods result in what are termed models for database
systems. Research performed at IBM provided much of the basis for these models, which are
still in use today.
A main driver in early database system designs was efficiency. One of the common ways to
make systems more efficient was to enforce a fixed length for database records, or at least have
a fixed number of elements per record (columns per row). This essentially avoids the repeating
group problem. If you are a programmer in just about any procedural language, you will readily
see that in this case, you can read each record of a database into a simple C structure. Real life
is rarely that accommodating, so we need to find ways to deal with inconveniently structured
data. Database systems designers did this by introducing different database types.