[Letter To Me] 프로젝트 ERD 설계 - 백엔드

▶ 요구사항 명세서

---

유저

    회원가입

          이메일(이메일 인증), 비밀번호, 이름

          카카오, 네이버로 회원가입

 

    로그인

          이메일, 비밀번호

          카카오, 네이버 로그인

 

    비밀번호 찾기

          이메일 인증을 통해 인증이 성공하면 비밀번호 변경 창으로 이동.

 

    이름 변경

          이름을 변경할 수 있음

 

    비밀번호 변경

          비밀번호를 변경할 수 있음. (로그인 된 상태라면 이메일 인증 X)

 

    이메일 변경(local_user만 변경 가능)

          이메일을 변경할 수 있음.

 

    회원 탈퇴

          회원 탈퇴를 할 수 있음. 회원 탈퇴 시 비밀번호를 입력해서 일치 시 탈퇴 가능

 

    프로필 사진 업로드

          프로필 사진을 업로드 할 수 있음.

 

 

편지

    편지 작성

          회원가입 한 이메일로 편지가 전송 됨.

          얼마 뒤에 보낼지 입력 가능 (분 단위까지)

          제목, 내용, 보낼 날짜와 시간, 작성한 시간

 

    편지 조회

          웹 내에서 작성한 편지를 확인할 수 있음.

          하지만 설정한 날짜가 되어야지 내용을 확인할 수 있고,

          설정한 날짜 전까지는 설정한 날짜, 제목만 확인 가능

 

    편지 저장

          쓰던 편지를 저장 할 수 있음

          저장하면 저장된 편지 페이지로 쓰던 편지가 감(저장된 날짜, 제목과 함께)

 

    편지 저장하지 않고, 나가기

          편지를 저장하지 않았습니다. 나가시겠습니까? 띄어주고 나가기

 

    저장된 편지 삭제

          정말로 편지를 삭제하시겠습니까? 삭제하려면 빈칸에 편지의 이름을 적어야함.

 

위 요구사항 명세서를 바탕으로 ErdCloud에서 ERD를 설계해주었다.

 

 

 

 

 

▶ ERD 설계

---

이렇게 ERD를 짜주었다.

 

 

 

 

▷ Soft Delete 방식을 사용하는 이유

---

유저나 편지 삭제는 Soft Delete를 사용해서 deleted_at 필드가 NULL 이면 지워지지않은것, 시간이 적혀있으면 그 시간에 지워진 것이다.

이번 프로젝트에서 Soft Delete를 사용하는 이유는 다음과 같다.

1. 만약에 편지를 잘못 삭제하더라도 복구하기 쉽게하기 위해서.

2. 그냥 Soft Delete를 사용해보고 싶어서...

 

 

 

 

▷ letters와 draft_letters를 나눈 이유

---

letters와 draft_letters의 필드는 거의 유사하므로, letters에 is_draft 라는 이름의 boolean 필드를 넣어줘도 되지 않나?

라는 생각을 했지만,

 

letters와 draft_letters를 나눈 이유는 draft_letters는 content와 send_at이 NULL일 수 있지만, letters는 NULL일 수 없기때문이다.

 

 

 

 

▷ 소셜 계정, 로컬 계정, 사용자 테이블을 분리한 이유

---

또users 쪽을 보면 local_users와 social_users로 나눴는데,

이는 3가지 이유가 있다.

1. 확장성
   • 현재는 kakao와 naver 두개의 소셜로그인만 생각했지만 추후 구글이나 페이스북 등 추가로 들어올 수 있는 소셜로그인을 대비함.
   • 만약 구글이나 페이스북 로그인을 추가해야 한다면, social_users 테이블에 provider 값으로 "google"이나 "facebook"을 추가하면 된다.
   • 별도의 테이블을 추가할 필요 없이, 기존 구조에 간단히 새로운 값을 추가하는 것만으로 새로운 소셜 로그인 제공자를 지원할 수 있다.
2. 유지보수성
   • 소셜 로그인 제공자별로 별도의 테이블을 두지 않고, social_users라는 단일 테이블에서 관리함으로써 유지보수성을 크게 향상시킴.
   • 테이블이 많아질수록 관리가 복잡해지기 때문에, 가능한 한 통합된 테이블을 사용하는 것이 유지보수 측면에서 유리함.
3. 데이터 무결성 유지
   • users에 login_type 필드를 추가해서 한 테이블에서 처리하는 방식은 최소 하나 이상의 필드에 NULL 값이 들어가게된다.
   • NULL 값이 많아지면 데이터의 의미가 불분명해지고, 데이터 무결성을 유지하기가 어려워진다.
   • 하지만 위 방식은 각 테이블이 해당 유형의 데이터에 맞는 필드만 가지고 있기 때문에, 불필요한 NULL 값이 줄어들고, 각 필드가 항상 유효한 데이터를 가질 수 있다.

따라서, 위 3가지 이유로 소셜 계정, 로컬 계정, 사용자 테이블을 분리해서 DB를 설계했다.

users 테이블에는 모든 계정들에게서 필수적이고 공통되는 필드들이 존재한다.

 

 

 

 

▷ local_users와 social_users에서 식별관계를 사용한 이유

---

이전 개념정리 포스팅에서 식별관계와 비식별관계에 대해서 설명한적이 있다.

 

 local_users와 social_users에서 식별관계를 사용한 이유는

local_users나 social_users 테이블의 레코드는 독립적으로 존재할 수 없으며,

반드시 users 테이블에 존재하는 특정 사용자에 대한 정보여야 하기 때문이다.

 

정리하면

local_users와 social_users의 레코드는 users 테이블의 레코드 없이는 존재할 수 없으며, 이를 보장하기 위해 식별관계를 사용하였다.

 

 

 

 

 

 

이렇게 ERD 설계를 마쳤고, 다음에는 API 명세서 작성으로 돌아오겠다.