Professional SQL Server™ 2005 Programming

5.2. Constraint Naming

Before we get down to the nitty-gritty constraints, I'll digress for a moment and address the issue of naming constraints.

NOTE

For each type of constraints that you 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_Customers_145C0A3F. This is a SQL Server generated name for a primary key on the Customers table of the Accounting database, which you recreate (we get rid of the old one from last chapter and rebuild it) later in the chapter. The PK is for primary key, which is the major thing that makes it useful. The Customers is for the Customers 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_Customers.

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, you know that it's a CHECK constraint, but you know nothing about the nature of the CHECK.

Because you can have multiple CHECK constraints on a table, you could wind up with all these (or other randomly ...