Beginning Microsoft SQL Server 2008 ... - S3 Tech Training

that my users can’t sell a product at a loss, or perhaps something as simple as CKCustomerPhoneNo on
a column that ensures that phone numbers are formatted properly.
As with the naming of anything that we’ll use in this book, how exactly you name things is really not all
that important. What is important is that you:
❑ Be consistent.
❑ Make it something that everyone can understand.
❑ Keep it as short as you can while still meeting the preceding rules.
❑ Did I mention to be consistent?
Key Constraints
There are four different types of common keys that you may hear about in your database endeavors.
These are primary keys, foreign keys, alternate keys, and inversion keys. For this chapter, we’ll only take
a look at the first three of these, as they provide constraints on a database.
An inversion key is basically just any index (we cover indexes in Chapter 9) that does not apply some
form of constraint to the table (primary key, foreign key, unique). Inversion keys, rather than enforcing
data integrity, are merely an alternative way of sorting the data.
Keys are one of the cornerstone concepts of database design and management, so fasten your seatbelt
and hold on tight. This will be one of the most important concepts you’ll read about in this book, and
will become absolutely critical as we move on to normalization in Chapter 8.
PRIMARY KEY Constraints
Chapter 6: Constraints
Before we define what a primary key actually is, let’s digress slightly into a brief discussion of relational
databases. Relational databases are constructed on the idea of being able to “relate” data. Therefore, it
becomes critical in relational databases for most tables (there are exceptions, but they are very rare) to
have a unique identifier for each row. A unique identifier allows you to accurately reference a record
from another table in the database, thereby forming a relation between those two tables.
This is a wildly different concept from what we had with our old mainframe environment or the ISAM
databases (dBase, FoxPro, and so on) of the ’80s and early ’90s. In those environments, we dealt with
one record at a time. We would generally open the entire table, and go one record at a time until we
found what we were looking for. If we needed data from a second table we would then open that table
separately and fetch that table’s data, then mix the data programmatically ourselves.
Primary keys are the unique identifiers for each row. They must contain unique values (and hence cannot
be NULL). Because of their importance in relational databases, primary keys are the most fundamental of
all keys and constraints.
157