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

Chapter 6: Constraints
A table can have a maximum of one primary key. As I mentioned earlier, it is rare to have a table in
which you don’t want a primary key.
When I say “rare” here, I mean very rare. A table that doesn’t have a primary key severely violates the
concept of relational data — it means that you can’t guarantee that you can relate to a specific record.
The data in your table no longer has anything that gives it distinction.
Situations where you can have multiple rows that are logically identical are actually not that uncommon,
but that doesn’t mean that you don’t want a primary key. In these instances, you’ll want to take a look
at fabricating some sort of key. This approach has most often been implemented using an identity column,
although using a GUID is now an appropriate alternative in some situations.
A primary key ensures uniqueness within the columns declared as being part of that primary key, and
that unique value serves as an identifier for each row in that table. How do we create a primary key?
Actually, there are two ways. You can create the primary key either in your CREATE TABLE command or
with an ALTER TABLE command.
Much of the rest of this chapter makes use of the Accounting database you created in Chapter 5. The
assumption is that the Accounting database is as it was at the end of Chapter 5 after using the Management
Studio to create tables in the database.
Creating the Primary Key at Table Creation
158
Don’t confuse the primary key, which uniquely identifies each row in a table, with a
GUID, which is a more generic tool, typically used to identify something (it could be
anything, really) across all space and time. While a GUID can certainly be used as a
primary key, they incur some overhead, and are usually not called for when we’re
only dealing with the contents of a table. Indeed, the only common place that a
GUID becomes particularly useful in a database environment is as a primary key
when dealing with replicated or other distributed data.
Let’s review one of our CREATE TABLE statements from the previous chapter:
CREATE TABLE Customers
(
CustomerNo int IDENTITY NOT NULL,
CustomerName varchar(30) NOT NULL,
Address1 varchar(30) NOT NULL,
Address2 varchar(30) NOT NULL,
City varchar(20) NOT NULL,
State char(2) NOT NULL,
Zip varchar(10) NOT NULL,
Contact varchar(25) NOT NULL,
Phone char(15) NOT NULL,
FedIDNo varchar(9) NOT NULL,
DateInSystem smalldatetime NOT NULL
);
This CREATE statement should seem old hat by now, but it’s missing a very important piece — our
PRIMARY KEY constraint. We want to identify CustomerNo as our primary key. Why CustomerNo? Well,
we’ll look into what makes a good primary key in the next chapter, but for now, just think about it a bit.