PHP and MySQL Web Development - P41 pdf

II
Using MySQL
7 Designing Your Web Database
8 Creating Your Web Database
9 Working with Your MySQL Database
10 Accessing Your MySQL Database from the Web with PHP
11 Advanced MySQL
09 525x part2 1/24/03 3:40 PM Page 167
09 525x part2 1/24/03 3:40 PM Page 168
7
Designing Your Web Database
NOW THAT YOU ARE FAMILIAR WITH
the basics of PHP, we’ll begin looking at inte-
grating a database into your scripts.As you might recall, in Chapter 2, “Storing and
Retrieving Data,” we talked about the advantages of using a relational database instead of
a flat file.They include
n
RDBMSs can provide faster access to data than flat files.
n
RDBMSs can be easily queried to extract sets of data that fit certain criteria.
n
RDBMSs have built-in mechanisms for dealing with concurrent access so that you
as a programmer don’t have to worry about it.
n
RDBMSs provide random access to your data.
n
RDBMSs have built-in privilege systems.
In more concrete terms, using a relational database allows you to quickly and easily
answer queries about where your customers are from, which of your products is selling
the best, or what type of customers spend the most.This information can help you
improve the site to attract and keep more users.The database that we will use in this sec-

tion is MySQL. Before we get into MySQL specifics in the next chapter, we need to
discuss
n
Relational database concepts and terminology
n
Web database design
n
Web database architecture
Following chapters cover
n
Chapter 8,“Creating Your Web Database,” covers the basic configuration you will
need in order to connect your MySQL database to the Web.
n
Chapter 9,“Working with Your MySQL Database,” explains how to query the
database and add and delete records, all from the command line.
10 525x ch07 1/24/03 3:35 PM Page 169
170
Chapter 7 Designing Your Web Database
n
Chapter 10,“Accessing Your MySQL Database from the Web with PHP,” explains
how to connect PHP and MySQL together so that you can use and administer
your database from a Web interface.
n
Chapter 11,“Advanced MySQL,” covers some of the advanced features of MySQL
that can come in handy when developing more demanding Web-based applica-
tions.
Relational Database Concepts
Relational databases are, by far, the most commonly used type of database.They depend
on a sound theoretical basis in relational algebra.You don’t need to understand relational
theory to use a relational database (which is a good thing), but you do need to under-

stand some basic database concepts.
Tables
Relational databases are made up of relations, more commonly called tables.A table is
exactly what it sounds like—a table of data. If you’ve used an electronic spreadsheet,
you’ve already used a relational table.
Let’s look at an example.
In Figure 7.1, you can see a sample table.This contains the names and addresses of the
customers of a bookstore, Book-O-Rama.
CustomerID
CUSTOMERS
Name Address City
1Julie Smith 25 Oak Street Airport West
2 Alan Wong 1/47 Haines Avenue Box Hill
3 Michelle Arthur 357 North Road
Yarraville
Figure 7.1 Book-O-Rama’s customer details are stored in a table.
The table has a name (Customers), a number of columns, each corresponding to a differ-
ent piece of data, and rows that correspond to individual customers.
Columns
Each column in the table has a unique name and contains different data. Each column
has an associated data type. For instance, in the Customers table in Figure 7.1, you can
see that CustomerID is an integer and the other three columns are strings. Columns are
sometimes called fields or attributes.
10 525x ch07 1/24/03 3:35 PM Page 170
171
Relational Database Concepts
Rows
Each row in the table represents a different customer. Because of the tabular format, they
all have the same attributes. Rows are also called records or tuples.
Values

Each row consists of a set of individual values that correspond to columns. Each value
must have the data type specified by its column.
Keys
We need to have a way of identifying each specific customer. Names usually aren’t a very
good way of doing this—if you have a common name, you’ll probably understand why.
Take Julie Smith from the Customers table for example. If I open my telephone directo-
ry, there are too many listings of that name to count.
We could distinguish Julie in several ways. Chances are, she’s the only Julie Smith liv-
ing at her address.Talking about “Julie Smith, of 25 Oak Street,Airport West” is pretty
cumbersome and sounds too much like legalese. It also requires using more than one
column in the table.
What we have done in this example, and what you will likely do in your applications,
is assign a unique CustomerID.This is the same principle that leads to you having a
unique bank account number or club membership number. It makes storing your details
in a database easier. An artificially assigned identification number can be guaranteed to be
unique. Few pieces of real information, even if used in combination, have this property.
The identifying column in a table is called the key or the primary key.A key can also
consist of multiple columns. If for example, we had chosen to refer to Julie as “Julie
Smith, of 25 Oak Street,Airport West,” the key would consist of the Name, Address, and
City columns and could not be guaranteed to be unique.
Databases usually consist of multiple tables and use a key as a reference from one table
to another. In Figure 7.2, we’ve added a second table to the database.This one stores
orders placed by customers. Each row in the Orders table represents a single order,
placed by a single customer.We know who the customer is because we store their
CustomerID.We can look at the order with OrderID 2, for example, and see that the
customer with CustomerID 1 placed it. If you then look at the Customers table, you can
see that CustomerID 1 refers to Julie Smith.
The relational database term for this relationship is foreign key. CustomerID is the pri-
mary key in Customers, but when it appears in another table, such as Orders, it is
referred to as a foreign key.

You might wonder why we chose to have two separate tables—why not just store
Julie’s address in the Orders table? We’ll explore this in more detail in the next section.
10 525x ch07 1/24/03 3:35 PM Page 171