You 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 probably understand why. Consider Julie Smith from the Customers table, for example. If you open your telephone directory, you may find too many listings of that name to count.
You could distinguish Julie in several ways. Chances are, she’s the only Julie Smith living 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 your 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, you choose 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. Figure 8.2 shows a second table added 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.You know who the customer is because you store her CustomerID.You 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