답변.

관련 테이블(예: "주문"과 "고객")은 관계형 데이터베이스에서 처음부터 존재했지만 초기 단계에서는 무결성 제어를 프로그래밍 논리를 통해 수동으로 구현해야 했습니다. SQL의 발전으로 내장 제약 조건(FOREIGN KEY)과 자동 작업(CASCADE)이 등장했습니다.

문제의 역사:

데이터베이스는 불완전한 레코드가 없도록 무결성을 유지하기 위한 메커니즘이 필요했습니다(예: 존재하지 않는 고객의 주문). FOREIGN KEY는 표준이 되었고 CASCADE 옵션은 삭제 및 수정 시 동기화를 자동화했습니다.

문제:

CASCADE 작업이 없으면 기본 테이블의 행을 삭제하거나 업데이트할 경우 오류가 발생하거나 "고아" 데이터가 생깁니다. 이 작업을 애플리케이션에 맡기면 관리의 복잡성이 증가하고 대량 작업 시 사고 위험이 따릅니다. 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 — 외래 키 값 자동 업데이트.
복잡한 시나리오에서는 사용자 정의 작업을 위해 트리거를 구현할 수 있음.

트릭 질문.

CASCADE 삭제가 모든 관계에 대해 항상 최선의 방법입니까?

아니요: "히스토리" 데이터나 아카이브 정보의 경우 CASCADE 삭제가 귀중한 정보를 잃게 할 수 있습니다. 각 관계의 비즈니스 가치를 이해하는 것이 중요합니다.

부모 테이블의 PRIMARY KEY에 외래 키가 포함되지 않을 경우 ON UPDATE CASCADE가 작동합니까?

대부분의 DBMS에서 외래 키는 CASCADE 지원을 위해 고유 또는 PRIMARY KEY를 참조해야 합니다. 그렇지 않으면 명령이 작동하지 않습니다.

CASCADE 체인이 허용된 중첩 깊이를 초과할 수 있습니까(재귀)?, 그렇다면 어떻게 됩니까?

예: 대규모 CASCADE의 경우 깊이 한도를 초과할 수 있습니다(예: SQL Server에서 32). 이는 오류와 작업 롤백을 유발합니다.

일반적인 오류 및 안티 패턴

약한 제어 하의 CASCADE 삭제 — 중요한 데이터 손실의 잠재적 원인.
대량 변경 사항을 기록할 필요성을 무시함.
성능을 고려하지 않은 트리거 설계(예: 무한 재귀를 발생시킬 수 있음).

실제 사례

부정적 사례

공급업체 및 주문 관리 시스템에서 ON DELETE CASCADE를 적용하여 고객이 중요한 공급업체를 실수로 삭제했을 때 모든 주문이 자동으로 삭제되고 공급 이력이 사라졌습니다. 데이터를 복구하는 것은 불가능했습니다.

장점:

최소한의 수동 작업.

단점:

비즈니스 역사 손실.

긍정적 사례

ON DELETE SET NULL을 사용하고 로그 작성을 위한 트리거를 추가했으며, 고객 기록 삭제 후에도 주문 이력이 유지되었습니다(비활성 상태로 변경됨) 때문에 우연한 대량 삭제가 발생하지 않았습니다.