[DB] 테이블 구분 컬럼 타입을 숫자로 하는 이유

Question

싱글 테이블에서 DTYPE과 같은 테이블 구분 컬럼에숫자를 사용하는 경우가 많아 보이던데 조회 시 성능 이점 때문인가요?

르매 · Accepted Answer

이런 컬럼을 저는 코드성 컬럼이라고 부릅니다. 회원 상태, 상품 유형 및 각종 구분 코드와 같은 것들이죠.RDB에서 4가지 방법을 사용할 수 있습니다.하나 하나 별도 테이블로 만들고 PK-FK 참조 관계를 맺어 주기 예를 들면 회원 상태라는 테이블이 있고, &#34;회원 상태 ID가 1이면 정상, 2이면 휴면, 3이면 탈퇴&#34;와 같은 데이터가 들어 있는거죠. 그럼 회원 테이블에서 회원 상태 테이블을 참조하는 방식입니다.enum 유형을 사용합니다. DBMS가 enum 유형을 지원할 때만 사용할 수 있습니다. 회원 테이블에 user_status enum('active', 'dormant', 'leave') 와 같은 컬럼을 만드는 방식입니다.varchar 유형을 사용합니다. 2항의 방법과 유사한데, enum을 사용하지 않고 문자열을 넣어 줍니다. 회원 테이블에 user_status varchar(10)으로 컬럼을 만들고, active/dormant/leave와 같이 값을 넣어 주는 방식입니다.마지막으로 일반화 기법입니다. 1항의 방법은 과정규화로 취급합니다. 정규화한 것은 맞지만 같은 유형의 테이블이 과도하게 많이 만들어지기 때문입니다. 일반화는 비슷한 유형의 테이블 구조를 하나만 만들어서 공유하여 사용하는 걸 말합니다. 보통은 code_kinds 테이블과 codes 테이블을 만들어서 이 두 테이블에 모든 코드 정의를 넣어 두고, codes 테이블의 code_id에 해당하는 정수 값을 각각의 테이블에서 참조관계를 맺지 않고 사용하는 방식입니다. codes 테이블의 내용을 배열로 표현하면 아래와 같게 됩니다. [ {&#34;code_id&#34;: 1, &#34;code_name&#34;: &#34;active&#34;}, {&#34;code_id&#34;: 2, &#34;code_name&#34;: &#34;dormant&#34;}, {&#34;code_id&#34;: 3, &#34;code_name&#34;: &#34;leave&#34;} ] 1번 각각의 테이블 - 장점 : ㄴ 정의하지 않은 값이 제약조건에 의해 입력 불가하므로 데이터 무결성을 보장한다. ㄴ 새로운 구분값을 추가하기 용이하다. ㄴ 참조하는 테이블에서 정수를 저장하므로 저장 공간 측면에서 I/O 성능에 유리하다. - 단점 : ㄴ 과정규화로 인해 똑같은 유형의 테이블이 많이 생기고 관리하기 어렵다. ㄴ 가독성이 떨어진다.2번 enum 코드 컬럼 - 장점 : ㄴ 가독성이 좋다. ㄴ enum에 정의한 값만 넣을 수 있으므로 데이터 무결성을 보장한다. ㄴ 스트링의 길이가 길어도 데이터 저장할 때는 ordinal 값을 사용하기 때문에 대개 1byte만 차지해서 I/O에 성능에서 유리하다. - 단점 : ㄴ enum 정의를 변경하기 번거롭고, 작업할 때 테이블이 잠길 수 있다.3번 문자열 코드 컬럼 - 장점 : ㄴ 가독성이 좋다. ㄴ 새로운 값을 추가하기 용이하다. - 단점 : ㄴ 저장공간을 많이 차지하기 때문에 I/O 성능에서 불리하다. ㄴ 무결성을 DB 수준에서 보장해주지 못한다. (아무 값이나 넣는대로 다 들어간다) 4번 일반화 - 장점 ㄴ 참조하는 테이블에서 정수를 저장하므로 저장 공간 측면에서 I/O 성능에 유리하다. ㄴ 새로운 값을 추가하기 용이하다. - 단점 ㄴ 가독성이 떨어진다. ㄴ 무결성을 DB 수준에서 보장해주지 못한다. (테이블로 분리되어 있으나 FK를 쓰지 않기 때문)프로젝트 마다 방법을 바꿔서 모두 적용해 봤습니다.제 경험으로는 2번이 제일 좋았지만, 단점으로 언급한 것처럼 enum의 정의가 바뀔 때.. 이걸 프로덕션 DB에 적용하는 과정에서 특정 조건일 때 장애의 우려가 있습니다. enum을 지원하지 않는 DB도 있구요.종합적으로 저는 4번을 추천합니다. 떨어지는 가독성은 간단하게 툴을 만들어 해결합니다. 컬럼 이름을 인풋으로 넣으면 값에 대한 key/value 쌍을 볼 수 있어서.. 즉, user_status 값이 3이면 탈퇴를 의미한다는 보여주는 툴인데, 이런 방식으로 보완해서 사용하고 있습니다.문자열로 직접 넣는 방법은 유연하고 가독성 면에서 좋습니다만.. 대용량 데이터베이스에서는 I/O 싸움이 됩니다. 스트링 보다는.. 정수 값이 여러 모로 성능 부담을 줄여주니까요. 이런 컬럼은 종종 복합 인덱스를 구성하기 때문에 더 그렇습니다.

Clickin · Answer

dtype이라는 게 뭐죠..? 예를 들면 게시판 테이블에서 게시판 종류별로 따로 테이블 만들지 않고 한 테이블에서 구분자를 나눈다는 말씀이신가요개인적으로는 해당 항목도 VARCHAR로 사용하는 편이 더 편리하긴 한데 조회 성능도 성능이고 차지하는 용량도 작은 장점이 있습니다.명칭에 대한 문제는 별도의 참조용 코드매핑 테이블이 있으면 해결되고요

집킨 · Answer

구분 컬럼에 인덱스를 걸지 말지는 데이터의 패턴에 따라 다릅니다카디널리티가 너무 낮으면 인덱스의 효과 대비 비용이 더 많아질수 있거든요그리고 구분 컬럼에 숫자를 쓰는거면 구분 개념에 대응하는 테이블이 별도로 있고 그 테이블의 pk를 외래키로 참조하는 컬럼일 가능성이 높습니다이게 아니고 단순히 구분 개념 자체로 숫자로 쓰는거라면 마치 자바에서 enum의 ordinal로 enum의 값을 다루는것과 마찬가지의 비효율 끝판왕인겁니다

[DB] 테이블 구분 컬럼 타입을 숫자로 하는 이유

3개의 답변

Q&A 목록