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

Chapter 6: Constraints
We can then build one or more tables that reference the CreditCardID column of our domain table. With
referential integrity, any table (such as our Orders table) that is defined as referencing our CreditCard
table will have to have a column that matches up to the CreditCardID column. For each row that we
insert into the referencing table, it will have to have a value that is in our domain list (it will have to have
a corresponding row in the CreditCard table).
We’ll see more of this as we learn about FOREIGN KEY constraints later in this chapter.
Constraint Naming
156
Before we get down to the nitty-gritty of constraints, we’ll digress for a moment and address the issue of
naming constraints.
For each of the different types of constraints that we will be dealing with in this
chapter, you can elect not to supply a name — that is, you can have SQL Server provide
a name for you. Resist the temptation to do this. You’ll quickly find that when
SQL Server creates its own name, it isn’t particularly useful.
An example of a system-generated name might be something like PK__Employees__145C0A3F. This is
an SQL Server–generated name for a primary key on the Employees table of the Accounting database,
which we will create later in the chapter. The “PK” is for primary key (which is the most useful naming
element), the Employees is for the Employees table that it is on, and the rest is a randomly generated
value to ensure uniqueness. You only get this type of naming if you create the primary key through
script. If you created this table through Management Studio, it would have a name of PK_Employees.
That one isn’t too bad, but you get less help on other constraints; for example, a CHECK constraint used
later in the chapter might generate something like CK__Customers__22AA2996. From this, we know
that it’s a CHECK constraint, but we know nothing of what the nature of the CHECK is.
Since we can have multiple CHECK constraints on a table, you could wind up with all of these as names
of constraints on the same table:
❑ CK__Customers__22AA2996
❑ CK__Customers__25869641
❑ CK__Customers__267ABA7A
Needless to say, if you needed to edit one of these constraints, it would be a pain to figure out which was
which.
Personally, I either use a combination of constraint types with a phrase to indicate what it does or the name(s)
of the column(s) it affects. For example, I might use CKPriceExceedsCost if I have a constraint to ensure