[Architecture] 일기 × 카테고리 N:M 관계 설계 (Enum vs DB, 중간 테이블, JPA 연관관계 매핑까지)

 

 

일기 도메인에 '활동 카테고리'  기능을 추가하면서, 테이블 설계부터 JPA 엔티티 매핑까지 전체 과정을 기록해 보려고 한다.

처음에는 단순하게 Enum으로 처리하려 했는데, 고민을 거듭할수록 구조가 점점 커졌다 ...

 

 

🚨 고민 배경

일기에 '활동 카테고리'를 매핑하는 기능을 기획했다.

예를 들어 하나의 일기에 "데이트", "업무", "약속" 같은 카테고리를 여러 개 붙일 수 있어야 한다.

 

1. 카테고리 데이터를 어떻게 관리할 것인가?

2. 일기와 카테고리의 관계를 어떻게 설정할 것인가?

3. JPA 연관관계 매핑을 어떻게 해야 하는가?

 

➡️ 하나하나 풀어보니 생각보다 고려할 게 많았다.

 

 

 

 

🤔 고민했던 선택지

 

1. 카테고리 데이터 관리 방법 : Enum vs DB 테이블

A. Enum으로 관리

enum class ActivityCategory {
    FAMILY_EVENT, DATE, WORK, FRIENDS_MEETING, ALONE_TIME
}

 

상수로 관리할 경우 쉽고 빠르게 개발이 가능하지만, 추후 유저별 커스텀 기능을 추가하려면 기존 로직 수정이 많이 발생한다

 

 

B. DB 테이블로 관리

유저별 커스텀 카테고리 확장이 자유롭지만, 테이블 설계가 복잡해진다는 단점이 발생한다.

 

 

2. 관계 설정: 1:N vs M:N

처음에는 '일기 하나에 카테고리 하나'라고 기획을 했었는데,

생각해보니 하루에 여러 활동들을 할 것을 고려해서 '하나의 일기에 여러 카테고리가 매핑'되는 것으로  변경했다.

 

일기 1개 → 카테고리 N개
카테고리 1개 → 일기 N개

 

➡️ `M:N(다대다)` 관계에는 중간 테이블이 필요하므로, DiaryActivityCategory 테이블을 도입하기로 했다.

 

 

 

🛠 최종 테이블 설계

 

활동 카테고리 테이블

ActivityCategory
├── id (PK)
├── name (카테고리 이름)
├── user_id (FK, nullable)

 

`user_id`가 null이면 기본 카테고리 null이 아니면 해당 유저가 추가한 커스텀 카테고리로 구분했다.

MVP 단계에서는 기본 카테고리만 사용하지만, 나중에 커스텀 기능이 추가돼도 구조를 바꿀 필요가 없다.

 

 

중간 테이블

DiaryActivityCategory
├── id (PK)
├── diary_id (FK, NOT NULL)
├── activity_category_id (FK, NOT NULL)
└── UNIQUE(diary_id, activity_category_id)  ← 복합 유니크 제약조건

 

✅ 복합 유니크 제약조건을 걸어서, 같은 일기에 같은 카테고리가 중복 매핑되는 것을 DB 레벨에서 방지했다.

 

 

전체 관계 요약

User ← ActivityCategory    (1:N 단방향)
User ← Diary               (1:N 단방향)
Diary ↔ DiaryActivityCategory ↔ ActivityCategory  (M:N, 중간 테이블)

 

 

 

📚 JPA 연관관계 매핑

 

ActivityCategory → User

 

방향 : 단방향

FK 위치 : ActivityCategory의 user_id 

주인 : ActivityCategory

매핑 : `@ManyToOne` + `@JoinColumn`

 

 

Diary → User

 

방향 : 단방향

FK 위치 : Diary의 user_id 

주인 : Diary

매핑 : `@ManyToOne` + `@JoinColumn`

 

 

Diary ↔ DiaryActivityCategory

 

방향 : 양방향

FK :  DiaryActivityCategory의 diary_id 

주인 : DiaryActivityCategory

매핑 : 주인은 `@JoinColumn`, 반대는 `mappedby`

 

 

 

 

ActivityCategory → DiaryActivityCategory

 

방향 : 단방향

FK : DiaryActivityCategory의 activity_category_id

주인 : DiaryActivityCategory

매핑 : `@ManyToOne` + `@JoinColumn`

 

 

 

 

➡️ FK를 실제로 가지고 있는 쪽이 연관관계의 주인(owning side)이다.

 

 

 

 

🔑 @JoinColumn의 의미

내가 했던 오해 : `@JoinColumn(name = "...")` = 상대 테이블의 PK ❌

실제 의미: `@JoinColumn(name = "...")` = 내 테이블에 있는 FK 컬럼의 이름 ✅

 

class DiaryActivityCategory(
    @ManyToOne(fetch = FetchType.LAZY)
    @JoinColumn(name = "diary_id", nullable = false) // ⬅️ DiaryActivityCategory 테이블의 diary_id 컬럼
    val diary: Diary,
 )

 

 

 

 

양방향 매핑: 주인 vs mappedBy

// DiaryActivityCategory (주인) - FK를 직접 관리
@ManyToOne(fetch = FetchType.LAZY)
@JoinColumn(name = "diary_id", nullable = false)
val diary: Diary,

// Diary (반대쪽) — DiaryActivityCategory의 diary 필드를 따라감
@OneToMany(mappedBy = "diary", orphanRemoval = true, cascade = [CascadeType.ALL])
var diaryActivityCategories: MutableList<DiaryActivityCategory> = mutableListOf()
    protected set

 

➡️ `mappedBy = "diary"`는 DiaryActivityCategory 엔티티의 `diary` 필드명을 가리킨다. 컬럼명이 아니다!