https://www.erdcloud.com/d/XyPHd55PTnKNXEjkp

2025. 7. 03 18:20 @Anonymous

플레이리스트의 구독자 관련 디스커션

<aside> 🤔

쟁점 : “구독자”를 플레이리스트 테이블의 컬럼으로 둘 것이냐, “구독” 테이블로 분리하여 둘 것이냐

</aside>

1. 플레이리스트 테이블의 “구독자” 컬럼

@ElementCollection
@CollectionTable(name = "playlist_subscribers")
private List<Long> subscriberIds;

<aside> 🥤

플리 1 - 유저 1, 2, (3)

장점:

• 조회가 빠름...? -> 유저 테이블에서 다시 조회해야하지 않나...

단점: -> 무결성, 외래키 제약 조건 위배 -> ** 특정 유저의 구독 플레이리스트 조회 시 모든 플레이리스트를 스캔해야 함 --> 리스트 크기 제한

</aside>

1. “구독” 테이블로 분리

<user 클래스>
@OneToMany(mappedBy = "user")
    private List<UserPlaylistSubscription> playlistSubscriptions = new ArrayList<>();

< playlist 클래스 >
@OneToMany(mappedBy = "playlist")
    private List<UserPlaylistSubscription> subscriptions = new ArrayList<>();

@Entity
@Table(name = "USER_PLAYLIST_SUBSCRIPTIONS")
public class UserPlaylistSubscription {
    @Id
    @GeneratedValue(strategy = GenerationType.IDENTITY)
    @Column(name = "SUBSCRIPTION_ID")
    private Long id;
    
    @ManyToOne
    @JoinColumn(name = "USER_ID")
    private User user;
    
    @ManyToOne
    @JoinColumn(name = "PLAYLIST_ID")
    private Playlist playlist;
    
    @Column(name = "SUBSCRIBED_AT")
    private LocalDateTime subscribedAt;
    
    @Column(name = "NOTIFICATION_ENABLED")
    private Boolean notificationEnabled = true;
}

<aside> 🥤

<구독> 플리1 유저1 플리1 유저2

단점:

• 테이블이 하나 더 생김
• 조인이 필요 -> n+1 문제 해결 필요 ( fetch join, @EntityGraph ... )

장점:

• 무결성 보장, 외래키 제약조건 ok
• 추가 속성 쉽게 넣기 가능 (구독 날짜...? - 딱히 의미는 없겠지만... 알림 설정 정도,,,? 새 콘텐츠가 추가된 경우 알림 같은)
• 성능 최적화 가능 ( 인덱싱 )

</aside>

<aside> 🎉

최종적으로 “구독” 테이블로 분리를 선택

<사유>

1. Join에 대한 단점을 상쇄할 수 있으며
2. 플레이 리스트 컬럼으로 두었을 때의 장점이 모호하기 때문이다. </aside>