[데이터베이스] 좋은 데이터 베이스 설계란? (feat.파워 오브 데이터베이스)

잘못된 DB설계의 문제점

1. 작은 요구사항 변경이 생겼는데 기존 데이터베이스에 많은 변경이 일어나야 한다면, 이 변경을 수용하기 위해 기존 테이블을 쪼개고 기존 데이터들을 정제해서 다시 넣어야 합니다. 이러한 작업을 하는 동안 서비스가 얼마간 정지될 수 있으며, 개발자들의 많은 시간을 소모시킨다.

   → 비용이 많이 든다.

2. 비효율적인 데이터베이스 구조로 인해 고객이 서비스를 이용하는데 많은 시간이 걸려 서비스를 이탈하게 된다.

   → 돈을 덜 벌게 된다.

---

좋은 데이터베이스 설계란?

‘파워 오브 데이터베이스’의 저자이자 20년 이상 경험을 가진 RDBS의 베테랑 개발자 마이클 J. 헤르난데즈는 다음과 같은 목적에 초점을 맞추어 설계해야 한다고 말한다.

• 무결성
  • 데이터베이스 내에 모든 값은 언제나 정확한 값을 유지해야 한다.
• 유연성
  • 데이터베이스 구조는 요구사항 변화에 대해 수정이 쉬워야 한다.
• 확장성
  • 데이터베이스 구조는 기능 확장에 대해서 수정이 쉬워야 한다.

‘성능’에 대한 고려는 가장 마지막에 해야한다. 왜냐하면, 성능 개선을 위한 설계안의 반영이 종종 가장 중요한 무결성을 해치는 결과를 낳기 때문이다.

---

테이블 설계 방법

1. 예비 테이블 만들기

• 필요한 필드를 정리하여 예비 필드 목록을 구조화 한다.

2. 테이블은 단일 주제를 나타내야 한다.

• 테이블이 단일 주제 혹은, 사건일 수 있는 주제로 정한다.

3. 기본 키를 가진다.

• 기본키는 레코드를 식별하고 테이블 관계를 설정하기 위해 필요하다.
• 기본키는 자연키와 인조키로 구분할 수 있다.
  • 자연키
    • MySQL의 InnoDB스토리지 엔진의 경우, 테이블 자체가 클러스터링 인덱스가 되기 때문에 자연키를 기본키로 한다면 따로 인덱스를 구성할 필요 없다.
    • 그러나, 비즈니스 요구사항의 변화가 생긴다면 기본키로 사용하던 자연키를 변경해야 한다는 단점이 있다.

      예를들어, 회원 테이블의 주민번호를 기본키로 사용중에 주민번호를 저장하지 못하도록 법이 개정된다면 문제가 생길 수 있다.

  • 인조키
    • 비즈니스 요구사항 변화에 전혀 영향을 받지 않기 때문에 변경할 필요가 없다.
    • 인덱스를 위한 필드가 추가되어 테이블이 커진다.
• 결론: 자연키와 인조키를 비교했을 때, 유연성이 성능보다 우선순위가 높기에 기본키를 인조키로 설정하는 것이 바람직하다는 결론이다.
  • 유연성 > 성능

4. 다중값 또는 다중 부분 필드를 포함하지 않는다.

• 예를들어, 하나의 컬럼에 다중 값이 들어가야 한다면 다중 값이 적용되어야 하는 테이블을 따로 생성해야한다.
• 이후, id를 이용하여 PK, FK를 설정한 뒤 다중 값과 일대다 관계를 맺어준다.

5. 계산된 필드는 포함하지 않는다.

예를들어, 전체금액과 할인금액을 계산한 최종 금액이 산출되는 프로그램이라면 테이블에는 전체금액과 할인금액에 대한 컬럼만 존재하고 최종금액에 대해서는 저장하지 않는다.

6. 외래키 외 불필요한 중복 필드는 제거한다.

• 중복되는 필드는 저장공간을 차지할 뿐이다.
• 수정이 일어날 경우 동기화가 되지 않아 무결성을 무너뜨리기 쉽다.

7. 필드 명세 설정하기

• 필드 이름
• 데이터 타입
  • char vs varchar

    • char: 고정길이를 가지고 있다. 따라서 저장되는 데이터의 길이가 일정하지 않으면 저장 공간이 낭비된다.

    • varchar: 가변길이를 가지고 있다. 10글자를 저장하는 varchar는 apple을 그대로 ‘apple’로 저장한다. 하지만 저장되는 데이터 크기에 딱 맞게 데이터 공간이 배정되기 때문에 더 긴 길이의 문자로 수정되어야 한다면 레코드 전체를 다른 곳으로 옮겨서 새로 저장해야한다.

    • 결론: 저장공간은 결국 성능과 관련되어 있기 때문에 저장공간이 커진다는 의미는 테이블의 크기가 커진다는 것과 같다. 테이블의 크기가 커질수록 데이터를 찾는데 필요한 시간이 길어진다.

      웹 서비스에서 사용하는 데이터베이스의 기능 중(CRUD) 조회의 성능이 가장 중요하다. 왜냐하면 하나의 글이 작성되고 2~3번 수정될 때, 게시글의 조회는 최소 10번이기 때문이다.

  • DATETIME vs TIMESTAMP
    • TIMESTAMP: TIME ZONE에 따라 저장된 시간을 볼 수 있다. 그러나 UTC로 저장되기 때문에 MySQL에서 자동으로 변환해줄 수 있다.
    • DATETIME: 수동으로 변환해줘야 한다.
    • 결론: 자동변환이 되는 TIMESTAMP를 사용한다면 유리한점이 많지만 2038년 1월 19일까지만 저장할 수 밖에 없는 문제가 있어 DATETIME을 사용하는 것이 좋다.
      • Year 2038 problem
• 허용 가능한 데이터 길이
• 값의 범위
• NULL 허용 여부
• 기본값

8. 다대다 관계는 다대일 관계로 풀어준다.