효율적인 RDB 설계 방법

# DB를 잘 설계해야하는 이유

 

어플리케이션을 하나 만들기 위해서는 굉장히 많은 양의 데이터를 처리해야 합니다. 우리는 보통 이 문제를 DBMS를 사용하여 무수한 데이터를 저장하고 원할때마다 알맞게 꺼내씁니다. 하지만 실생활에도 그렇듯이 어떤 방식으로 정리하고 관리하느냐에 따라 사용할때의 속도(성능)이 달라집니다. 여러 데이터베이스 종류가 있지만 그 중에 RDB를 사용할때 조금 더 효율적인 DB를 설계할 수 있는 방법에 대해 알아보겠습니다.

 

효율적인 DB의 가장 궁극적인 형태는 '시간'과 '돈'을 최대한 아낄 수 있는 형태입니다. 서비스도 결국 '비용'으로 운영되고 관리되기 때문입니다. 예외적으로 다른 선택지를 택해야 할때도 있지만 비로소 이렇게 해야 나중에 발생할 '비용'도 최대한 줄일 수 있습니다.

 

그렇다면 최적의 방법이란게 존재할까요?

바로, 무결성, 유연성, 확장성을 만족하는 DB를 설계하는 것입니다. 여기서 추가적으로 속도를 고려할수도 있습니다. 하지만 속도에 초점을 맞추었을때는 종종 무결성을 해치기 때문에 앞에 3가지를 최대한 만족하면서 고려하는것이 좋습니다. 그러면 몇 가지 설계방법에 대해 알아보겠습니다.

# 테이블 설계

 

1. 하나의 테이블은 단일 주제를 나타내야합니다.
2. 기본키를 가져야합니다.
   # 자연키 vs 인조키 
   자연키 - 인덱스를 구성할 필요가 없지만 추후에 변경해야 될 상황에 쳐했을때 수정하기 어려워집니다. (성능)
   인조키 - 변경할일이 없지만 테이블의 크기가 커지는 문제가 있습니다. (유연성)
   
   
   
3. 다중값 또는 다중 부분 필드를 포함하지 않습니다.
   
   
4. 계산된 필드들을 포함하지 않습니다.
   
   
5. 외래키 외에  불필요한 중복 필드 포함 x
   
   

 

 

# 필드 명세 설정

 

1. CHAR vs VARCHAR
   CHAR - 고정 길이 (테이블의 크기가 커짐 -> 조회 성능이 떨어짐)
   VARCHAR - 가변길이 (수정 성능이 떨어짐)
   
   
   
2. DATETIME vs TIMESTAMP
   DATETIME - 자동으로 타임존 변환 X, 1000~9999년 까지 제한
   TIMESTAMP - UTC를 기준으로 저장, 1970~2038년 까지 제한, 자동으로 타임존 변환
   
   
3. ENUM vs 참조테이블
   ENUM - 조회속도가 빠르고 용량이 적지만 ENUM 값들과 연관된 데이터를 저장할 수 없습니다.
   참조테이블 - 연관된 값을 같이 저장할수 있지만 조회속도가 느리고 쿼리에 값을 명확하게 넣을수 없습니다.

 

 

# 관계 설정

 

1. 다대다 관계 풀어주기
   다중값 필드나 중복 데이터가 포함될 수있기 때문에 반드시 풀어줘야함
   
   
   
2. 식별 관계 vs 비식별 관계
   식별 관계 - 자식 테이블이 부모키의 기본키를 자신의 기본키에 포함하는 경우, 데이터의 정합성 유지를 DB에서 한번 더 할 수 있습니다, 구조 변경이 어렵습니다.
   비식별 관계 - 부모 테이블의 기본키 또는 유니크 키를 자신의 기본키로 사용하지 않고, 외래 키로 사용하는 관계, 변경되는 요구사항을 유동적으로 수용가능, 무결성을 보장하지 않습니다.

 

# 정규화

 

1. 제 1 정규형
   테이블에 속한 모든 필드의 값이 원자 값으로만 이루어져야 한다.
   
   
   
2. 제 2 정규형
   테이블이 제 1 정규형에 속하고, 기본키가 아닌 모든 속성이 기본키에 완전 함수 종속되면 제 2 정규형에 속합니다.
   
   
   
3. 제 3 정규형
   제 3정규형은, 제 1정규형, 제 2정규형을 만족하고, 이행적함수종속관계를 갖지 않는 것을 말합니다.

 

 

 

 

# 규칙을 파괴해도 될 시기

 

1. 테이블이 사건형 테이블인 경우
   각각의 레코드가 모두 독립적이다.
   테이블에 수정 또는 삭제가 거의 일어나지 않는다  (정규화의 이유가 사라짐)
   
   
   
2. 성능이 문제 되는 경우
   줄어든 무결성보다 성능 향상이 정말 가치있는지, 쉽게 말해서 '돈'을 더 벌어다 주는지 충분히 생각해서 진행해야 합니다.

 

 

마지막으로 쿼리 최적화를 해주면 효율적인 RDB 설계를 마칩니다.

 

 

 

 

 

 

 

# reference

https://velog.io/@sontulip/how-to-db-design  

chatgpt