UMC Spring - Ch.4 DATABASE 설계 & AWS RDS 설정 (1)

4장에서는 DB 설계를 다룹니다.

이제 데이터베이스를 상황에 따라 설계하는 방법을 배운 뒤 직접 설계해보도록 하겠습니다.

데이터베이스를 설계해야하기 때문에 MySQL과 ERD에 관한 개념을 간단히 정리는 아래 링크를 참고해주세요!

그럼 본문으로 들어가도록 하겠습니다.

ERD는 간단히 말해 데이터베이스의 설계도입니다. 따라서 프로젝트 진행 시 초기에 ERD를 보다 원활한 프로젝트를 진행할 수 있습니다.

4장에서는 데이터베이스의 설계에 관해 배운다고 했는데요, 보다 구체적인 상황은 다음과 같습니다.

• 유저 테이블을 어떻게 설계하는 것이 좋은지
• N : M(다대다) 관계는 어떻게 하는 것이 좋은지
• 알림을 보내야 하는 경우는 어떻게 하는 것이 좋은지

4장에서는 도서 대여 관리 app의 DB를 예시로 DB를 설계하고 있습니다.

우선 관련 요구사항을 살펴보겠습니다.

---

사용자 관련 요구 사항

1. 카카오 소셜 로그인을 구현 할 예정이다.
2. 회원 탈퇴 기능이 필요하다.
3. 이름, 닉네임, 전화번호, 성별이 필요하다.

책 관련 요구 사항

1. 사용자가 책 여러 권을 대여할 수 있다.
2. 책은 하나의 카테고리가 있다.
3. 책은 제목, 설명에 대한 정보가 필요하다.
4. 책 소개 페이지에 해시태그가 붙을 수 있고,
   책 한 권에 해시태그 여러 개가, 해시태그 하나가 여러 책에 붙을 수 있다.
5. 사용자가 책 설명 페이지에서 책에 좋아요를 누를 수 있다.
6. 책 카테고리 별로 현재 몇 개의 책이 있는지 집계가 필요하다.

알림 관련 요구 사항

1. 알림은 공지 관련 알림, 책 반납 시간 임박 알림, 마케팅 알림이 있을 수 있다.

---

위 요구사항을 바탕으로 ERD를 설계할 예정인데 단계별로 추가될 때 마다 n차 ERD로 나누어 설명하였다.

1차 ERD

이 요구사항을 보면 단순히 테이블이 사용자, 책, 알림으로만 구성된다고 생각할 수 있다. 그러나 카테고리에 관한 설명을 보면 단순히 책 테이블 안에서 해결하기에는 복잡하다는 것을 알 수 있다.
-> 그래서 bookCategory 테이블을 추가했다.

위의 ERD처럼 설계하기 위해서 기본적으로 3가지 조건을 지켜야한다.

1. 테이블 이름& 칼럼 이름은 소문자!
   단어 구분은 밑줄로!(대문자xx)

2.기본키로 엔티티의 유일한 값을 채택하기(X)
index를 따로 만들어 기본키로 사용(O)

3. 기본키 타입은 bigint로! (추후 확장 고려)

2차 ERD

이 ERD에서 book테이블의 description, member테이블의 gender, created_at, updated_at을 수정/추가해 아래와 같은 ERD가 됩니다.

1. book테이블의 description
   사실 1차 ERD와 차이는 없지만 설명을 하기 위해서 데려왔다.
   description은 text(string과 같은 역할) vs. varchar(50) 이 둘 중에 결정을 해야한다.
   이 경우 description에 지정한 글자수 제한이 없으므로 길이 제한이 없는 text를 자료형으로 선택했다.

2. member테이블의 gender
   gender는 int(0이면 남자, 1이면 여자) vs. varchar(10) 이 둘 중에 결정해야한다.
   이때 varchar로 설정해 enum으로 관리할 수 있기에 이번에는 varchar(10)을 선택했다.
   각자 편한 걸로 고르면 된다!

3. created_at, updated_at
   최신순 정렬 기능을 위한 속성이다.
   이때 자료형인 datetime(6)은 밀리초 소수점 6자리까지 구분한다는 의미이다. 이렇게 밀리초 단위로 아주 작은 부분으로 나누면 케이스별로 같은 시간을 사용해 겹치는 걸 방지할 수 있다!

3차 ERD

마지막으로 member테이블에 status와 inactive_date 속성을 두어 추후에 삭제 기능을 구현할 때 사용한다.

이렇게 status, inactive_date 속성을 두는 이유는 soft delete와 연관이 있다.

우선 Hard Delete vs. Soft Delete 로 나누어 살펴보자.

• Hard Delete
  :HTTP Method 중 Delete로 바로 삭제!

  hard delete의 단점은 다음과 같은 경우에서 알 수 있다.

  • 1. 회원 탈퇴를 철회하는 경우
       ->이미 삭제해버려서 복구할 수 없다악!!
  • 2. join 연산을 이용해 매일 인기 상위 사용자 5명을 집계해 보여주는 경우
       ->1등이 탈퇴를 하면 2, 3, 4, 5등만 남아있네???

  이렇게 hard delete의 경우 문제를 불러 일으킬 수 있으니 지양하는 게 좋다!

• Soft Delete
  : HTTP Method 중 Patchfh, 일단 비활성 상태로 두고, 일정 기간동안 비활성인 경우 자동 삭제가 되도록!

  사용하는 변수:

  • status: 비활성 여부

  • inactive_date: 비활성한 기간

    Q. 어떻게 자동으로 지우죠??
    A. 정해진 시간에 자동으로 실행되는 프로세스인 batch를 이용해서 검사한 뒤, inactive 된지 일정기간만큼 지나면 삭제합니다!

연관 관계

다음은 연관관계에 대해 알아보겠습니다.
이번에 다룰 연관관계는 총 5가지로, 사용자:책, 책:책 카테코리, 책:해시태크, 사용자: 좋아요, 알림입니다.

왁! 너무 배고파서 닭강정 먹고 오겠습니다. 호다다다닥