Question

When setting up foreign keys in SQL Server, under what circumstances should you have it cascade on delete or update, and what is the reasoning behind it?

This probably applies to other databases as well.

I’m looking most of all for concrete examples of each scenario, preferably from someone who has used them successfully.

Answer 1

Summary of what I’ve seen so far:

• Some people don’t like cascading at all.

Cascade Delete

• Cascade Delete may make sense when the semantics of the relationship can involve an exclusive ‘is part of‘ description. For example, an OrderLine record is part of its parent order, and OrderLines will never be shared between multiple orders. If the Order were to vanish, the OrderLine should as well, and a line without an Order would be a problem.
• The canonical example for Cascade Delete is SomeObject and SomeObjectItems, where it doesn’t make any sense for an items record to ever exist without a corresponding main record.
• You should not use Cascade Delete if you are preserving history or using a ‘soft/logical delete’ where you only set a deleted bit column to 1/true.

Cascade Update

• Cascade Update may make sense when you use a real key rather than a surrogate key (identity/autoincrement column) across tables.
• The canonical example for Cascade Update is when you have a mutable foreign key, like a username that can be changed.
• You should not use Cascade Update with keys that are Identity/autoincrement columns.
• Cascade Update is best used in conjunction with a unique constraint.

When To Use Cascading

• You may want to get an extra strong confirmation back from the user before allowing an operation to cascade, but it depends on your application.
• Cascading can get you into trouble if you set up your foreign keys wrong. But you should be okay if you do that right.
• It’s not wise to use cascading before you understand it thoroughly. However, it is a useful feature and therefore worth taking the time to understand.