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

Chapter 6: Constraints
168
FROM OrderDetails;
-- Now, let’s delete the Order record
DELETE Orders
WHERE OrderID = 1;
-- Finally, look at both sets of data again
-- and see the CASCADE effect
SELECT *
FROM Orders;
SELECT *
FROM OrderDetails;
This yields some interesting results:
OrderID CustomerNo OrderDate EmployeeID
--------- ------------ -------------------- --------------
1 1 2000-07-13 22:18:00 1
(1 row(s) affected)
OrderID PartNo Description UnitPrice Qty
--------- ------- --------------------- ------------ ----
1 0R2400 This is another part 50.0000 2
1 4X4525 This is a part 25.0000 2
(2 row(s) affected)
(1 row(s) affected)
OrderID CustomerNo OrderDate EmployeeID
-------- ----------- ------------ -----------------------
(0 row(s) affected)
OrderID PartNo Description UnitPrice Qty
---------- ----------- --------------- ------------ --------
(0 row(s) affected)
Notice that even though we issued a DELETE against the Orders table only, the DELETE also cascaded to
our matching records in the OrderDetails table. Records in both tables were deleted. If we had defined
our table with a CASCADE update and updated a relevant record, then that, too, would have been propagated
to the child table.
It’s worth noting that there is no limit to the depth that a CASCADE action can reach. For example, if we
had a ShipmentDetails table that referenced rows in OrderDetails with a CASCADE action, then
those, too, would have been deleted just by our one DELETE in the Orders table.
This is actually one of the danger areas of cascading actions. It’s very, very easy to not realize all the different
things that one DELETE or UPDATE statement can do in your database. For this and other reasons,
I’m not a huge fan of cascading actions. They allow people to get lazy, and that’s something that’s
not usually a good thing when doing something like deleting data!