[projectec] 회원 DB 설계

우선 로그인과 회원 가입에 필요한 DB를 설계하기로 했다.

모든 DB를 전부 만든 후 시작하기보다는, 최대한 많은 내용을 담을 수 있도록, 확장성을 고려하면서 필요한 기능마다 추가한다.

거대한 프로젝트가 아닌 만큼 RDB를 최대한 활용하기로 결정했다.

요구사항 분석

회원 정보와 관련된 컬럼을 브레인스토밍을 통해 생각해보면 다음과 같다.

• 로그인 ID 또는 이메일
• 비밀번호
• 회원 가입일
• 회원 상태 (휴면, 삭제 등)
• 선택 약관 동의 여부
• 소셜미디어 로그인 여부 (소셜미디어 이름, 토큰 등)
• 찜한 상품 목록
• 장바구니
• 접속일, 비밀번호 변경일, 주문 취소 이력, ...

여기서 로그인과 회원 가입에 필요한 컬럼을 선정하고, 정규화해야 한다.

기획서가 있으니 요구 사항을 파악해보자.

ERD 그려보기

로그인과 회원 가입에 필요한 컬럼을 선정했다면 ERD를 그려보자.

위 그림은 MySQL Workbench로 그린 ERD이다. 왜 이렇게 나눴는가? 주목해야 할 점을 의식의 플로우대로 적어보겠다.

유저 테이블

유저에는 id (auto incremental pk), 이메일, 암호화된 비밀번호, 회원 상태, 생성일 컬럼을 넣었다. 선정된 컬럼들의 공통점은 다음과 같다.

1. 로그인과 회원 가입에 직접적으로 관련이 있다.
2. 데이터가 중복되지 않는다.
3. 컬럼이 늘어날 것 같지 않다.

왜?

선택 약관 테이블

선택 약관은 유저 테이블에 포함될 수 없을까?

선택 약관을 표현하는 방법에 두 가지가 생각났다. 그림으로 표현하면 다음과 같다.

첫 번째 방법은 약관 하나에 컬럼 하나씩 할당하는 방식이다.

이렇게 하면 유저 테이블에도 선택 약관 컬럼을 넣을 수 있지만, 확장성에서 불리해진다.

가령 새로운 약관3을 만든다면? 약관4를 만든다면?

컬럼을 계속해서 늘릴 수 밖에 없기 때문에, 서비스가 커지고 나면 점점 더 컬럼을 추가하기 부담 갈 것이다.

두 번째 방법은 약관이름과 동의 여부 컬럼으로 나누는 것이다.

이 방식은 약관이 몇개든간에 이 두 컬럼만 있으면 모든 걸 표현할 수 있다.

다만 위 방식에 비해 row가 더 많고, 약관에 뭐가 있는지 알아야 하고, 유저 테이블과 합칠 수 없기 때문에 조인을 해줘야 한다는 단점이 있다.

어떤 방식이 나아보이는가? 정답은 없겠지만, 난 확장성을 고려해 후자의 방식을 택했다.

(참고로 이 방식은 EAV라고 한단다 찾아보자.)

나머지 테이블

소셜 로그인과 로그 데이터 저장은, 로그인과 회원가입을 우선적으로 구현하기 위해서 나중에 고려하기로 했다.

DB 생성

ERD에 따라서 DB를 생성해보았다. 여러 ERD 에디터가 많고 대부분 SQL 추출이 가능하므로 잘 사용해보자.

CREATE TABLE `USER` (
  `USER_ID_NO` BIGINT(20) NOT NULL AUTO_INCREMENT,
  `USER_EMAIL` VARCHAR(255) NOT NULL,
  `USER_PWD` VARCHAR(255) NOT NULL,
  `USER_STATUS` INT NOT NULL DEFAULT 0,
  `USER_CREATED_AT` TIMESTAMP NOT NULL DEFAULT CURRENT_TIMESTAMP,
  PRIMARY KEY (`USER_ID_NO`))
ENGINE = InnoDB;


CREATE TABLE `TERM` (
  `TERM_ID_NO` BIGINT(20) NOT NULL AUTO_INCREMENT,
  `USER_ID_NO` BIGINT(20) NOT NULL,
  `TERM_NAME` VARCHAR(255) NOT NULL,
  `TERM_FLAG` TINYINT(1) NOT NULL DEFAULT 0,
  PRIMARY KEY (`TERM_ID_NO`),
  CONSTRAINT `FK_USER_TERM_ID`
    FOREIGN KEY (`USER_ID_NO`)
    REFERENCES `USER` (`USER_ID_NO`)
    ON DELETE NO ACTION
    ON UPDATE NO ACTION)
ENGINE = InnoDB;

마치며

다음엔 기획서 기준으로 로그인과 회원가입 로직을 구상해보고 구현하자.