A Customers table is referenced by both an Addresses table and an Invoices table. Deleting a customer should automatically remove that customer's addresses, but a customer who has invoices must not be deletable. Which foreign key configuration meets both requirements?
Select an answer to reveal the explanation.
Short Explanation
Each relationship gets its own delete rule, so think about each child separately. Addresses are disposable baggage that should follow the customer out the door, so they cascade; invoices are financial records you keep, so they restrict the delete. The trap is cascading everything and quietly wiping out your invoice history.
Full Explanation
Referential actions are defined per foreign key, so each child table can respond differently when a parent row is deleted. ON DELETE CASCADE deletes the dependent child rows automatically, which suits addresses that have no meaning without their customer. ON DELETE RESTRICT (or NO ACTION, which behaves similarly in most engines apart from timing) rejects the parent delete while any referencing child rows exist, which protects invoices that must be retained. Cascading on both relationships would satisfy the address requirement but silently delete invoices, destroying financial records. Reversing the rules restricts deletes because of addresses, which blocks ordinary cleanup, while cascading would erase invoices. Using SET NULL on addresses leaves orphaned address rows with a NULL customer reference instead of removing them, and it fails outright if the column is declared NOT NULL. Exam caveat: cascades can chain through several tables and remove far more data than expected, so document every cascading relationship and review it during change management. Operational check: in a test copy, delete a customer that has only addresses and confirm the addresses disappear, then attempt to delete a customer that has invoices and confirm the statement fails with a constraint violation.