회원 삭제 때 주문까지 CASCADE로 지우자는 제안이 나왔습니다. 외래키 삭제 정책은 무엇을 기준으로 정하나요?

외래키는 참조 무결성을 강제하지만 부모의 생명주기가 자식의 생명주기와 같다는 뜻은 아닙니다. 주문·결제처럼 독립 보관 의무와 역사적 의미가 있는 기록은 회원 삭제와 동시에 물리 삭제하면 안 될 수 있습니다.

동작 원리와 전제

CASCADE는 관련 행을 함께 지우고 RESTRICT·NO ACTION은 참조가 남은 삭제를 제한하며 SET NULL은 관계를 끊는 선택입니다. 세부 검사 시점과 deferred 제약은 엔진별로 다릅니다. NULL이 의미상 허용되는지, 삭제된 회원의 주문을 어떻게 표시할지 먼저 정합니다.

선택과 실패 처리

개인정보 삭제는 주문 자체 삭제와 익명화·필드 분리·접근 제한 중 정책에 맞는 방법을 선택합니다. 대규모 cascade는 많은 행·인덱스·로그를 바꾸며 긴 잠금과 복제 지연을 만들 수 있습니다. 작은 배치로 지울 때는 중간 상태와 재시작 키를 설계해야 합니다.

구체적인 사례와 검증

강좌의 마지막 수강 신청을 지우는 것과 강좌 자체를 지우는 것은 서로 다른 사건입니다. 수강 기록이 과거 성적을 보존해야 하면 강좌를 비활성화하고 참조를 남기는 모델이 맞을 수 있습니다. 삭제 정책은 관계형 제약 문법 이전에 각 데이터의 보존 의미에서 결정합니다. 대규모 cascade는 애플리케이션 로그에 부모 한 행 삭제만 보이더라도 수많은 자식 변경을 만들 수 있으므로 실제 영향 행·로그·락을 봅니다. 새 외래키를 도입할 때는 기존 고아 행을 먼저 대사하고, 삭제 migration 중 동시 삽입이 새 고아를 만들지 못하도록 단계와 권한을 정합니다.

부모 삭제·자식 동시 삽입·다단계 cascade·중단 후 재개를 시험합니다. ORM 옵션과 실제 DB 제약이 같은지 확인하며 애플리케이션만 검사해 경쟁을 남기지 않습니다. 외래키는 관계의 존재 규칙이고 삭제 권한과 보존 정책까지 자동 결정하지 않습니다.