Oracle on delete cascade

 

 

 

혼자서 코딩을 하던 중 특정 데이터가 삭제되지 않는 것을 확인했습니다. 연습용으로 작은 웹 사이트를 만들어봤는데, 회원 DB가 삭제되지 않았습니다. 이유는 회원테이블(USER TABLE)로 참조키가 설정되어있었기 때문이었습니다. 제가 구축하던 웹 사이트는 회원의 DB가 사라지면 오류가 발생하기 때문에 탈퇴를 한 회원이라면, 회원을 '탈퇴한 회원'으로 수정하고 나머지 회원의 개인정보를 null로 수정하였습니다.

 

그래도 만약에 자식으로 거슬러 내려가서 일일이 삭제하지않고, 바로 부모쪽에서 바로 삭제할 수 있는 방법을 알고싶었고, 다행히도 그러한 설정이 있어 이번 포스팅에서 알려드릴까 합니다.

 

on delete cascade

 

FOREIGN KEY를 이용하면 데이터를 외부에서 참조할 수 있습니다. 예를들어 USER 테이블의 userid라는 기본키가 있고,  USER테이블에서 userid를 참조하고 있는 MYPAGE의 userid라는 참조키가 있다고 가정을 할 때, USER테이블의 userid를 함부로 update, delete를 할 수 없습니다. 이유는 다른 테이블에서 사용 중이기 때문에 함부로 변경할 수 없기 때문입니다.

 

방법은 여러가지겠지만 크게 두가지로 나눌 수 있습니다. 해당 기본 키를 참조하는 모든 참조키를 삭제하고나서 기본키를 삭제하거나, on delete cascade를 사용하여 관련된 모든 키를 삭제하는 방법이 있습니다.

 

이번에는 on delete cascade를 사용하여 삭제하는 방법에 대해 알아보겠습니다.

 

CREATE TABLE TEST1(
    PK_COLUMN1 VARCHAR2(100),
    CONSTRAINT TEST1_PK PRIMARY KEY (PK_COLUMN1)
);

 

위는 TEST1이라는 테이블에 PK설정을 하였습니다.

 

CREATE TABLE TEST2(
    PK_COLUMN1 VARCHAR2(100),
    COLUMN2 VARCHAR2(100),
    CONSTRAINT TEST2_FK_PK_COLUMN1 FOREIGN KEY(PK_COLUMN1) REFERENCES TEST1(PK_COLUMN1)
    ON DELETE CASCADE
);

 

TEST2라는 테이블에서 TEST1의 컬럼을 참조하여 FK를 설정하였습니다. 맨 아랫줄을 보면 ON DELETE CASCADE설정을 하였습니다. 이는 원래의 PK인 TEST1테이블의 PK인 PK_COLUMN1의 데이터를 삭제했을 때 그 데이터에 참조된 데이터들을 모두 삭제하겠다는 설정입니다.

 

다음으로 테이블에서 데이터를 추가하겠습니다.

 

INSERT INTO TEST1 VALUES('MENU1');
INSERT INTO TEST1 VALUES('MENU2');

INSERT INTO TEST2 VALUES('MENU1', '김밥');
INSERT INTO TEST2 VALUES('MENU1', '튀김');
INSERT INTO TEST2 VALUES('MENU2', '오뎅');
INSERT INTO TEST2 VALUES('MENU2', '라면');

 

위의 두줄은 TEST1에 데이터를 추가했고, 나머지는 TEST2에 데이터를 추가했습니다. TEST2의 VALUES는 순서대로 PK_COLUMN1, COLUMN2입니다.

 

TEST2테이블을 조회하면 아래와 같은 데이터가 출력됩니다.

 

 

다음은 TEST1테이블에서 PK로 설정된 PK1_COLUMN1의 데이터인 MENU1을 삭제해보겠습니다. 원래라면 삭제가 되지 않지만, FK 설정 당시 ON DELETE CASCADE를 설정했기 때문에 삭제가 될 수 있음을 확인 할 수 있습니다.

 

DELETE FROM TEST1 WHERE PK_COLUMN1 = 'MENU1';

 

위의 쿼리를 실행하면,

 

 

 

 

MENU1이라는 데이터가 삭제됨과 동시에 TEST2의 FK인 PK_COLUMN1의 MENU1이라는 데이터도 삭제된 것을 확인할 수 있습니다.

 

 

 

 

 

 

 

자료참조

wakestand.tistory.com/205

m.blog.naver.com/PostView.nhn?blogId=pjt3591oo&logNo=220617636202&proxyReferer=https:%2F%2Fwww.google.com%2F