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

Chapter 6: Constraints
170
Let’s illustrate this “You can’t delete or update a referenced record” idea.
We just defined a couple of foreign keys for the Orders table. One of those references the EmployeeID
columns of the Employees table. Let’s say, for instance, that we have an employee with an EmployeeID of
10 who takes many orders for us for a year or two, and then decides to quit and move on to another job.
Our tendency would probably be to delete the record in the Employees table for that employee, but that
would create a rather large problem — we would get what are called orphaned records in the Orders
table. Our Orders table would have a large number of records that still have an EmployeeID of 10. If we
are allowed to delete EmployeeID 10 from the Employees table, then we will no longer be able to tell
which employee entered in all those orders. The value for the EmployeeID column of the Orders table
will become worthless!
Now let’s take this example one step further. Let’s say that the employee did not quit. Instead, for some
unknown reason, we wanted to change that employee’s ID number. If we made the change (via an UPDATE
statement) to the Employees table, but did not make the corresponding update to the Orders table, then
we would again have orphaned records. We would have records with a value of 10 in the EmployeeID
column of the Orders table with no matching employee.
Now, let’s take it one more step further! Imagine that someone comes along and inserts a new record
with an EmployeeID of 10. We now have a number of records in our Orders table that will be related to
an employee who didn’t take those orders. We would have bad data (yuck!).
Instead of allowing orphaned records, SQL Server, by default, restricts us from deleting or updating
records from the referenced table (in this case, the Employees table) unless any dependent records have
already been deleted from or updated in the referencing (in this case, Orders) table.
This is actually not a bad segue into a brief discussion on or about when a CASCADE
action makes sense and when it doesn’t. Data-integrity-wise, we probably wouldn’t
want to allow the deletion of an employee if there are dependent rows in the Orders
table. Not being able to trace back to the employee would degrade the value of our
data. On the other hand, it may be perfectly valid (for some very strange reason) to
change an employee’s ID. We could CASCADE that update to the Orders table with
little ill effect. Another moral to the story here is that you don’t need the same
CASCADE decision for both UPDATE and DELETE — think about each separately (and
carefully).
As you can see, although the foreign key is defined on one table, it actually placed restrictions on both
tables (if the foreign key is self-referenced, then both sets of restrictions are on the one table).
UNIQUE Constraints
These are relatively easy. UNIQUE constraints are essentially the younger sibling of primary keys in that
they require a unique value throughout the named column (or combination of columns) in the table. You
will often hear UNIQUE constraints referred to as alternate keys. The major differences are that they are not
considered to be the unique identifier of a record in a table (even though you could effectively use it that
way) and that you can have more than one UNIQUE constraint (remember that you can only have one primary
key per table).