答案。

相关的表（例如，“订单”和“客户”）从关系数据库的开始就出现了，但在早期，完整性控制需要通过程序逻辑手动实现。随着SQL的发展，出现了内置约束（FOREIGN KEY）和自动操作（CASCADE）。

问题背景：

最初，数据库需要维护完整性的机制，以避免“悬挂”记录（例如，没有现存客户的订单）。FOREIGN KEY成为标准，而CASCADE选项则自动化了删除和修改时的同步。

问题：

没有级联操作时，删除或更新主表中的行会导致错误或“孤立”数据。将此任务委托给应用程序通常会导致维护复杂性并在批量操作时存在事件风险。不当使用级联操作可能会引发雪崩式删除或破坏业务逻辑。

解决方案：

使用带ON DELETE CASCADE和ON UPDATE CASCADE的FOREIGN KEY可以自动维护完整性并正确同步相关表。在复杂场景中（例如，需要不仅删除而且记录操作的情况）可以使用触发器。

代码示例：

CREATE TABLE Customers (
  CustomerID INT PRIMARY KEY,
  Name NVARCHAR(100)
);

CREATE TABLE Orders (
  OrderID INT PRIMARY KEY,
  CustomerID INT,
  Amount DECIMAL(10,2),
  FOREIGN KEY (CustomerID) REFERENCES Customers(CustomerID)
    ON DELETE CASCADE
    ON UPDATE CASCADE
);

关键特点：

ON DELETE CASCADE — 删除父记录时自动删除子记录。
ON UPDATE CASCADE — 自动更新外键的值。
在复杂场景下，可以通过触发器实现自定义操作。

具有挑战性的问题。

级联删除是否始终是所有关系的最佳实践？

不是：对于“历史”数据或归档信息，级联删除可能导致有价值信息的丢失。了解每种关系的商业价值非常重要。

如果外键不在父表的主键中，ON UPDATE CASCADE有效吗？

在大多数DBMS中，外键必须引用唯一或主键以支持级联。否则，该命令将不会生效。

级联链条是否可能超出允许的递归深度限制，发生什么？

是的：在巨大的级联中，可能会超出深度限制（例如，在SQL Server中为32）。这将导致错误并回滚操作。

常见错误和反模式

在控制不严的情况下进行级联删除 — 潜在丢失重要数据。
忽视记录大量更改的必要性。
构造触发器时忽视性能（例如，引入无限循环）。

生活中的例子

消极案例

在供应商和订单管理系统中应用ON DELETE CASCADE — 客户意外删除了一个重要供应商，所有订单自动被删除，交付历史数据丢失。恢复数据变得不可能。

优点：

最少的手动工作。

缺点：

商业历史丢失。

积极案例

使用ON DELETE SET NULL，加上触发器记录 — 即使客户记录被删除，订单历史仍然得到保存（标记为过时），没有发生意外的大量删除。