DB설계

요구사항

[사용자 관련]

• 사용자는 회원가입 시 email, pw, 가입이유를 작성해야 한다.
• 닉네임을 랜덤 지정된다.
• 회원가입 시 가입 일시가 저장된다.
• 로그인 시 토큰을 통해 인증 절차를 거친다.
• 사용자는 폐급 / 특급 둘 중 하나의 계급을 갖는다.
• 사용자의 프로필 사진은 등급에 따라 해당 등급 갤러리의 최다 좋아요 사진으로 자동 설정된다.

[계약서 관련]

• 사용자는 중복해서 계약할 수 없다. 계약기간이 종료되어야만 새로운 계약을 할 수 있다.
• 계약 기간은 1주 / 2주 / 4주 3가지 중 선택한다.
• 한 번의 계약 시 최대 3개의 카테고리를 선택할 수 있다.
• 카테고리는 총 5개이다.
• 계약 시 사용자는 보증용 폐급 사진을 업로드해야 한다.
• 사용자는 계약 이름을 지정할 수 있다.
• 계약 기간동안 사용자는 달성한 일과를 카테고리별로 표시할 수 있다.
• 사용자는 계약 기간동안 카테고리 별로 달성 현황을 볼 수 있다.
• 계약 기간이 끝나면 해당 계약에 대한 카테고리별 달성율 그래프를 볼 수 있다.
• 계약기간 종료 후 계약 실패 시 보증용 사진이 메인페이지 사진 후보에 올라간다.
• 계약 성공 시 사용자는 금갤러리에 올라갈 사진을 제출해야 한다. 그 사진은 사용자의 금갤러리에 올라간다.

초기 설계

위의 요구사항을 참고하여 아래와 같이 DB를 설계했었다.

이 과정에서 Contract 테이블에 카테고리1, 2, 3 컬럼을 세 개 만들어도 되는것인지, 계약 진행상황에 대한 테이블은 어떻게 만들지 막막했다.

사용자가 달성 도장을 찍을 때마다 DB에 카테고리와 날짜를 입력할 지,
카테고리 별 행에 날짜 데이터를 배열로 입력할 지 고민했다.

또한 전체 유저의 실시간 랭킹을 보여주려고하는데, 이 기능을 구현하기 위해 구글의 Firebase를 사용해야 하는지와 같은 고민이 있었다.

이 DB를 가지고 현직 DBA에게 물어보았다.

생각보다(;;) 고쳐야할 점이 많았고, 실무에서 어떻게 하는지 들을 수 있었다. 다음은 그 내용을 정리한 것이다.

1. 실무에서는 FK는 표시만 해놓고 실제 구현은 하지 않는다.

• 데이터 입력, 삭제등의 관리가 어렵기 때문이다.
• 아마 MySql FK 걸어놓고 프로젝트 해봤다면 불편하다고 느꼈을 것이다.

2. 카테고리 테이블을 따로 만든다.

• 명확하게 하기 위해
• 카테고리 추가나 변경 시 관리를 용이하게 하기 위해

3. Contract 테이블에 카테고리 3개의 컬럼을 만들어도 된다.

• 카테고리별로 계약 기간이 다르거나, 한 계약에 카테고리의 수가 많아진다면 카테고리 컬럼을 하나만 만들어 각 카테고리 ID를 입력하도록 해야한다.
• 하지만 우리 프로젝트의 경우 하나의 계약서를 작성할 때 동일한 기간에 최대 3개의 카테고리만 선택할 수 있도록 해놓았기 때문에 카테고리 컬럼을 3개 만들어도 무방하다.
• 또한 코드로 구현하기가 더 쉽다.

4. Poop Gallery와 Gold Gallery를 굳이 나눌 필요 없다.

• 실무에서는 이런 경우 그냥 한 테이블로 만들고, 등급 컬럼을 추가해 구분하는 방식으로 구현한다고 한다.
• 굳이 두 테이블로 쪼갤 필요가 없다는 시각이었다.

5. 용어 사전을 만든다.

• 실무에서는 용어 사전이 따로 있다고 한다.
• 예를 들어 '계약' = CT, '번호' = NO, '일자' = DT 이런 식으로 단어마다 3~4글자씩 영어 약어를 정해놓는다.
• DB에서 해당되는 단어는 모두 사전의 단어와 동일해야 한다. 예를 들면 '시작일자' 컬럼의 '일자'와 '종료일자' 컬럼의 '일자' 모두 용어 사전의 'DT'로 동일해야 한다는 것이다.
• 우리 프로젝트의 경우 규모가 작으니 엑셀이나 다른 문서에 정리해두어도 무방하다고 한다.

6. 랭킹은 시간을 정해놓고 업데이트 해라

• 실무에서도 실시간 서비스는 부하가 크기 때문에 사장님이 특별지시하지 않는이상 안한다고 한다(...)
• 실시간 랭킹을 보여주기 위해 다른 DB를 쓰거나 코딩을 해서 시스템 부하를 크게 하지 말고, 그냥 업데이트 시간을 정해놓고 그 때만 업데이트하는 방식으로 구현해라
• 랭킹 관련 테이블을 따고 만들어 정해진 시간에 랭킹 업데이트를 하는 시스템을 만들어라.

그 밖에도 SQLD 시험지에서나 보았던 PK 여러개 만들기 ... 매우 당연하게 쓰는 것이었다. FK를 실제로 구현하지 않다보니 그렇게 하는 것 같다.

수정한 DB