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

Chapter 6: Constraints
Cascading Actions
164
One important difference between foreign keys and other kinds of keys is that foreign keys are bidirectional;
that is, they not only restrict the child table to values that exist in the parent, but they also check for child
rows whenever we do something to the parent (thus preventing orphans). The default behavior is for
SQL Server to “restrict” the parent row from being deleted if any child rows exist. Sometimes, however,
we would rather automatically delete any dependent records rather than prevent the deletion of the
referenced record. The same notion applies to updates to records where we would like the dependent
record to automatically reference the newly updated record. Somewhat more rare is the instance where
you want to alter the referencing row to some sort of known state. For this, you have the option to set
the value in the dependent row to either NULL or whatever the default value is for that column.
The process of making such automatic deletions and updates is known as cascading. This process, especially
for deletes, can actually run through several layers of dependencies (where one record depends on
another, which depends on another, and so on). So, how do we implement cascading actions in SQL
Server? All we need is a modification to the syntax we use when declaring our foreign key. We just add
the ON clause that we skipped at the beginning of this section.
Let’s check this out by adding a new table to our Accounting database. We’ll make this a table to store
the individual line items in an order, and we’ll call it OrderDetails:
CREATE TABLE OrderDetails
(
OrderID int NOT NULL,
PartNo varchar(10) NOT NULL,
Description varchar(25) NOT NULL,
UnitPrice money NOT NULL,
Qty int NOT NULL,
CONSTRAINT PKOrderDetails
PRIMARY KEY (OrderID, PartNo),
CONSTRAINT FKOrderContainsDetails
FOREIGN KEY (OrderID)
REFERENCES Orders(OrderID)
ON UPDATE NO ACTION
ON DELETE CASCADE
);
This time we have a whole lot going on, so let’s take it apart piece by piece.
Before we get too far into looking at the foreign key aspects of this, notice something
about how the primary key was done here. Instead of placing the declaration
immediately after the key, I decided to declare it as a separate constraint item. This
helps facilitate the multicolumn primary key (which therefore could not be declared
as a column constraint) and the clarity of the overall CREATE TABLE statement. Likewise,
I could have declared the foreign key either immediately following the column
or, as I did here, as a separate constraint item. I’ll touch on this a little bit later in the
chapter.
First, notice that our foreign key is also part of our primary key. This is not at all uncommon in
child tables, and is actually almost always the case for associate tables (more on this next chapter).