[Database] 친구 추가 관련 ERD 설계하기(팔로잉-팔로워)

프로젝트 도중 친구 관련 ERD를 작성하였는데,

이에 대하여 정리하면 좋을듯하여

정리해본다!

 

우선은 회원 기반의 서비스를 제작했는데,

 

친구를 신청하면 이에 대하여 신청을 받은 친구가 수락을 할 때까지 

친구의 상태가 되지 않고 대기해야하는,

게임에서 자주 볼 수 있는 친구 요청–수락–차단과 같은 상태 기반의 관계 관리 모델을 반영한 것이다.

 

 

이에 대하여 다음과 같이 설계하였다.

 

 

• 서비스에는 회원(Member) 개체가 존재한다.
• 회원 간의 관계를 표현하기 위해 Friend 테이블을 별도로 정의한다.
• 친구 관계는 단순히 양방향 연결이 아닌, 요청–승인–거절–차단 등의 다양한 상태를 가질 수 있다.

이를 나타내면 다음과 같다.

 

 

 

우선은 크게 member table이 존재하면,

이에 대하여 friend라는 "관계"에 대한 테이블을 생성한다.

 

friend_status에는 enum type으로 'ACCEPTED', 'REQUESTING', 'REJECTED', 'BLOCKED'의 값들을 저장한다.

(각각 수락됨, 요청 중, 거절됨, 차단됨 의 상태에 매핑됨)

 

 

Friend 테이블은 Member 테이블을 참조하는 관계 테이블로서,
sender_id와 receiver_id를 통해 양쪽 회원을 연결한다.

 

 

하나의 회원은 여러 개의 친구 요청을 보낼 수도, 받을 수도 있으므로
Member(1) : Friend(N) 의 관계로 매핑된다.

 

 

그렇다면 이와 비슷하게 팔로우와 팔로잉도 설계해보자

 

Friend가 상호 승인 기반(양방향) 관계. ACCEPTED가 되어야 서로 친구 라면,

 

Follow는 단방향 관계. A가 B를 팔로우하면 A의 피드에 B의 활동이 보이는 형식으로 회원 마다 공개 관련 설정에 따라서 다르다. 

만약 회원의 계정이 공개일 때, 그리고 비공개일 때마다 상황이 전부 다르다

 

• 공개 계정: 요청 즉시 FOLLOWING
• 비공개(잠금) 계정: REQUESTED 상태로 대기, 상대 승인 시 FOLLOWING

 

 

테이블 구조 (핵심 컬럼)

 

• follower_id : 팔로우를 하는 쪽 (FK → member.id)
• followee_id : 팔로우를 받는 쪽 (FK → member.id)
• follow_status : FOLLOWING | REQUESTED | REJECTED | BLOCKED <- 이 부분은 친구 관계에서도 동일하다. 하지만 만약 서로 둘 다 팔로우를 하고있다면 테이블이 두 개가 생성될 것이다.
• 감사/운영 컬럼: created_at, updated_at, (선택) deleted_at, memo(사유)

 

상태 정의

• FOLLOWING: 팔로우 성립
• REQUESTED: 비공개 계정 대상 요청 대기
• REJECTED: 요청 거절(기록 유지 용도—재요청 정책에 따라 유지/삭제)
• BLOCKED: 차단(팔로우 불가 및 검색/추천 제외)

차단은 Friend의 BLOCKED와 의미 동일하되, Follow 레벨에서도 단방향 차단을 허용하거나, 계정 단위 글로벌 블록 테이블을 별도로 둘 수 있다(운영 정책에 따름).

 

그리고 또한 팔로워의 수를 세는 것을 member 별로 가지고 있는 1:1 관계의 테이블로 설정하는 것도 가능하다.

어차피 중간의 참조를 많이 해야하기 때문이다

 

 

팔로잉-팔로워의 경우에는 공개/비공개 계정의 여부, 내가 내 자신을 팔로우하기는 금지 등등

운영에서 무결성 등을 보장하기 위하여 생각할 게 많으니

초기 설계를 잘 하자