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

Chapter 5: Creating and Altering Tables
Table Constraints
ON
Table constraints are quite similar to column constraints, in that they place restrictions on the data that
can be inserted into the table. What makes them a little different is that they may be based on more than
one column.
Again, I will be covering these in the constraints chapter, but examples of table-level constraints include
PRIMARY and FOREIGN KEY constraints, as well as CHECK constraints.
Remember when we were dealing with database creation, and we said we could create different filegroups?
Well, the ON clause in a table definition is a way of specifically stating on which filegroup (and, therefore,
physical device) you want the table located. You can place a given table on a specific physical device, or,
as you will want to do in most cases, just leave the ON clause out, and it will be placed on whatever the
default filegroup is (which will be the PRIMARY unless you’ve set it to something else). We will be looking
at this usage extensively in our chapter on performance tuning.
TEXTIMAGE_ON
This one is basically the same as the ON clause we just looked at, except that it lets you move a very specific
part of the table to yet a different filegroup. This clause is only valid if your table definition has
text, ntext, or image column(s) in it. When you use the TEXTIMAGE_ON clause, you move only the
BLOB information into the separate filegroup — the rest of the table stays either on the default filegroup
or with the filegroup chosen in the ON clause.
Creating a Table
130
OK, so why is a CHECK constraint a table constraint? Isn’t it a column constraint since
it affects what you can place in a given column? The answer is that it’s both. If it is
based on solely one column, then it meets the rules for a column constraint. If, however
(as CHECK constraints can), it is dependent on multiple columns, then you have
what would be referred to as a table constraint.
There can be some serious performance increases to be had by splitting your database
into multiple files, and then storing those files on separate physical disks.
When you do this, it means you get the I/O from both drives. Major discussion of
this is outside the scope of this book, but keep this in mind as something to gather
more information on should you run into I/O performance issues.
All right, we’ve seen plenty; we’re ready for some action, so let’s build a few tables.
When we started this section, we looked at our standard CREATE syntax of:
CREATE