[Practice-6] 단뱡향/양방향 선택 기준 (⭐⭐⭐)

기준 1. 데이터의 개수 (Cardinality)

"리스트에 담았을 때 메모리가 터질 가능성이 있는가?"

• ProductOption (옵션):
  • 한 상품에 옵션이 몇 개나 붙을까요? 색상, 사이즈 조합해봤자 보통 10개 내외, 많아도 100개를 넘지 않습니다.
  • 이 정도는 List에 담아서 메모리에 올려도 서버에 전혀 부담이 없습니다.
• Review (리뷰):
  • 인기 상품은 리뷰가 수천, 수만 개가 달립니다.
  • 이걸 List에 담는 순간, 상품 하나 조회하려고 리뷰 1만 개를 메모리에 퍼올리는 대형 사고가 터집니다. 그래서 리뷰는 페이징(Slice/Page)이 필수이고, 양방향을 끊어야 합니다.

2. 생명주기 (Lifecycle)와 종속성

"부모가 죽을 때 자식도 같이 죽어야 하는가? 그리고 함께 관리되는가?"

• ProductOption (옵션):
  • 상품이 삭제되면 옵션도 존재 의미가 없습니다. (무조건 삭제)
  • 상품을 등록할 때 옵션도 같이 등록하고, 상품을 수정할 때 옵션도 같이 수정합니다.
  • 즉, **"상품과 옵션은 한 몸(Aggregate)"**입니다. 이럴 때는 양방향 관계를 맺고 CascadeType.ALL, orphanRemoval = true를 걸어서 부모(Product)를 통해 자식(Option)을 관리하는 것이 훨씬 편하고 자연스럽습니다.
• Review (리뷰):
  • 상품이 등록될 때 리뷰가 같이 등록되나요? 아닙니다.
  • 리뷰는 **"다른 사용자(Member)"**가 나중에 생성하는 데이터입니다. 상품 관리(수정) 로직과 리뷰 작성 로직은 완전히 분리되어 있습니다. 굳이 한 몸으로 묶을 필요가 없습니다.

3. 조회 패턴 (Access Pattern)

"상세 페이지 들어갈 때 무조건 같이 보여줘야 하는가?"

• ProductOption (옵션):
  • 상품 상세 페이지에 들어가면, 사용자가 구매를 하려면 **옵션 선택 박스(Dropdown)**가 무조건 바로 떠야 합니다.
  • 즉, Product를 조회할 때 ProductOption도 거의 항상 같이 필요합니다.
• Review (리뷰):
  • 상세 페이지 로딩 시, 리뷰는 보통 하단 탭에 있거나, "더 보기"를 눌러야 나옵니다.
  • 최초 로딩 시점에 굳이 리뷰 데이터를 다 가져올 필요가 없습니다. (비동기로 따로 가져오는 경우가 많음)