[시행착오] 회원과 채팅방의 연관관계는 N:M일까? 1:N일까?

이 글은 Velog에서 이전한 글입니다. Velog 원문 보기

⭐️ 서론

내가 진행하는 프로젝트 중에는 Sucat 프로젝트가 있다.
이 프로젝트는 재학중인 대학교 커뮤니티이다. 기존의 대중적으로 많이 사용하는 커뮤니티 서비스가 이미 존재했지만, Sucat 프로젝트는 기존 서비스에 존재하지 않는 여러가지 기능과 특징을 추가했다.

대표적으로

• 게임 기능
  • 1:1 게임, 학과별 랭킹, 개인 랭킹
• 친구 기능
• 채팅 기능

크게 보면 이 3가지인데 이러한 기능들을 추가한 목적은 명확했다. 바로 '친목'이다.
요즘 대학생들을 보면 서로가 친해질 기회가 MT, 술자리 등 사교적인 자리에만 존재했다. 유명한 커뮤니티가 존재하지만 이는 철저한 익명성을 보장하기 때문에 오프라인에서의 친목까지 이어지기가 어려웠다.

때문에 1:1 게임 등을 통해서 친목의 기회를 만들고 게임이 끝난 후 친구 추가를 보낼 수 있도록 만들고자 했다. 친구 추가 관계에서는 원한다면 익명을 해제할 수 있도록 만들었다.

그런데 채팅 기능을 개발하던 중 고민이 생겼다.
아래는 채팅방과 회원 사이의 연관관계를 설정하던 중 생긴 고민과 해결 과정을 정리한 것이다.

📌 고민 사항

간단히 채팅 기능을 설명하자면 기본적으로 1:1 채팅이다.
하나의 채팅방에는 오직 2명의 회원만 존재한다.

내가 생각한 회원, 채팅방의 관계는 아래와 같다.

• 회원은 여러개의 채팅방을 가질 수 있다.
• 각 채팅방은 2명의 회원을 갖는다.

따라서 회원과 채팅방은 N:M 관계라고 할 수 있다.

그러나 여기서 고민이 생겼다.
N:M으로 설정할 수는 있지만, 그 경우에는 추가적인 엔티티가 필요했다. 일반적으로 N:M 관계를 표현하기 위해서는 중간 테이블(조인 테이블)을 생성해야 한다.

조인 테이블 예시

@Entity
public class ChatRoomMember {
    @Id
    @GeneratedValue(strategy = GenerationType.IDENTITY)
    private Long id;

    @ManyToOne
    @JoinColumn(name = "chat_room_id")
    private ChatRoom chatRoom;

    @ManyToOne
    @JoinColumn(name = "user_id")
    private User user;
}

이러한 조인 테이블을 추가하면 N:M 관계를 설정할 수는 있지만, 이 경우 구조가 복잡해지므로 N:M 관계를 만드는 것이 맞는지 고민이 됐다.

더 좋은 방법은 없을까?

📌 고민 해결

생각을 전환해서 아래처럼 생각했다.

• 회원: 1명의 회원은 N개의 채팅방에 참여할 수 있다.
• 채팅방: 각 채팅방은 2명의 회원을 가지고 있지만, 이는 각 채팅방에 대해 1:1 관계로 볼 수 있다.

따라서, 회원과 채팅방의 관계를 N:M이라고 표현하기보다는, 회원과 채팅방 간의 관계는 1:N이며, 각 채팅방은 두 명의 회원을 포함하는 형태이다.

결론적으로
회원과 채팅방은 1:N 관계이다. 다만 채팅방이 두 명의 회원을 포함할 뿐이다.

최종적으로 작성한 채팅방 엔티는 아래와 같다.

채팅방 엔티티

@Getter
@Entity
@NoArgsConstructor(access = AccessLevel.PROTECTED)
public class ChatRoom extends BaseEntity {

    @Id
    @GeneratedValue(strategy = IDENTITY)
    @Column(name = "chat_room_id")
    private Long id;

    @ManyToOne(fetch = FetchType.LAZY)
    @JoinColumn(name = "sender_id")
    private User sender;

    @ManyToOne(fetch = FetchType.LAZY)
    @JoinColumn(name = "reveiver_id")
    private User receiver;

    private String roomId;

    ...
}

요약

• N:N 관계: 추가적인 조인 테이블을 통해 표현 가능.
• 1:N 관계: 현재의 요구 사항에 맞는 더 간단한 방법.
  결론적으로, N:N 관계로 설정할 수는 있지만, 이 경우 구조가 복잡해지므로 요구 사항에 따라 가장 적합한 방법을 선택했다.
  현재의 경우에는 1:N 관계가 더 직관적이고 관리하기 쉬울 것이라고 생각해 1:N 관계로 설정했다.

개선점
현재도 더 나은 개선법이 있는지 고민하고 있다. 다만, 아직까지는 1:N 관계를 유지하는 것이 최선이라고 생각한다.
추후 기능을 개선한다면 아마 이 아래에 이어서 작성할 것 같다.