[DB] TRUNCATE, DELETE | RDBMS 삭제 명령어 비교

개요

로컬에 더미로 쌓아둔 데이터가 너무 많고 난잡해서 database 값들을 초기화했는데.. 여기서 문제가 생겼다.

 

 

현재 Table 구조는 상당히 복잡하게 연관관계가 매핑되어있다.

예를 들어, 유저가 회원가입을 하면 account 테이블이 생성되고, 이와 관련하여 account_a, account_b, account_c… 이런식으로 관계가 정의되어 있기에 update나 insert, delete 등의 명령어는 주의해서 사용해야 한다.

나처럼 무심코 정리했다간 에러지옥에 파묻힐것이다ㅠ.ㅠ

 

실서버나 staging과 같은 테스트 서버에 데이터를 쉽게/자주 조작하면 안되겠지만,

local은 테스트를 위해 이런저런 작업을 하게된다.

이때 무심코 delete를 하기보다는… truncate라는 명령어를 사용하는 것이 테이블 구조를 초기화하기에 편했다.

 

 

---

 

TRUNCATE

truncate는 truncate table; 과 같은 형식으로 쓰이며, table의 모든 행을 삭제하는 DDL(데이터 정의 언어)이다.

truncate를 실행하면 테이블 구조는 유지하면서 데이터만 다 날려 초기 상태로 만든다.

외래키, index와 같은 값들도 모두 삭제하고 실행 즉시 커밋되며, 롤백이 불가능하므로 사용에 주의가 필요하다.

 

 

---

데이터 무결성(Data Integrity)

 

이러한 작업이 가능한 이유는 RDBMS의 데이터 무결성 특징을 무시하기 때문이다.

 

Intengrity는 일관성 있고, 그대로 남아있다는 뜻을 가진다. 이 단어 뜻을 찾으면서 되게 재밌는 해석을 찾아서 공유해본다. 🤣

줏대있고 당당한 느낌. 소신대로 언행일치를 한다는 뜻 

 

 

데이터 베이스 특히, 관계형 데이터베이스는 이러한 소신이 있다.

• 모든 테이블이 primary key를 가져야 하며 기본 키로 선택된 열은 고유하고, null을 허용하지 않는다.
• 외래 키 값이 두 가지 상태 가운데 하나에만 속한다.
• 정의된 범위에서 RDBMS의 모든 열이 선언되도록 규정한다.
• 하드웨어적인 오류로 인한 데이터 손실 또는 변경을 막기위한 보호장치가 있다.

 

이러한 무결성을 없애고, primary key가 부여된 튜플값이라고 하더라도 truncate라는 명령어로 모두 원복할 수 있다는 것이다.

 

 

---

TRUNCATE와 CASCADE

 

개요에 설명된 상황처럼, 테이블 간의 연관관계가 복잡한 상황에서는 하나 이상의 table의 변동 사항이 큰 여파를 가져올 수 있다.

 

이런 여파를 해결하기 위해 TRUNCATE table1, table2… 로 상태를 원복하는데, 이때 CASCADE를 같이 사용할 수 있다.

cascade는 종속이라는 뜻으로 쉽게 말해서 table 간의 명령어가 연쇄적으로 일어나는 것이다.

JOIN으로 매핑된 table 간에 어떤 명령어를 연쇄적으로 적용할 수 있는 옵션이다.

 

 

아래와 같은 방식으로 사용한다.

truncate table1, table2 cascade

 

 

---

TABLE 삭제 명령어

TRUNCATE와 비슷한 삭제 명령어를 알아보도록 하자.

 

 

DELETE

DELETE는 테이블에서 특정 조건을 만족하는 행(튜플)만을 삭제하는 DML(데이터 조작 언어)이다.

 

여기서 WHERE 절을 생략하면 테이블에 있는 모든 레코드를 삭제한다. 

이때, 모든 레코드를 삭제하더라도 테이블의 구조는 남아 있기 때문에 디스크에서 테이블을 완전히 제거하는 DROP과는 다르다.

delete는 truncate와 다르게 롤백이 가능하다.

DELETE FROM table WHERE some_condition;

 

 

롤백과 관련한 내용은 여기에 잘 나와있다!!

 

---

 

TRUNCATE와 DELETE 비교

 

 

해당 사이트에 상세하게 나와있다.

SQL Delete Vs. SQL Truncate | Simplilearn

 

가장 와닿은 차이점은 테이블 ID의 재설정 부분이다. 이 특성을 통해 개요의 문제 상황을 해결할 수 있었기 때문이다.

 

---

오늘의 교훈

• 내가 찾는다고 될 일이 아닌 케이스도 있으니 시간 낭비하지말고 모르겠으면 도움 요청하고 감사하기~
• 로컬 DB라고 하더라도 함부로 이것저것 막 하지않기
• 적어도 내가 운영 및 개발하는 사이트라면 DB table 관계는 모두 파악하고 꿰찰 것(table 72개.. 틈틈히 보자.)