실전 스프링 부트와 JPA활용1 강의를 듣고 공부 목적으로 정리한 내용입니다.
모르는 부분이 많아 공부하면서 적고 있습니다.
JPA 강의 수강 후 수정 예정입니다.
목차
- 요구사항 분석
- 도메인 모델과 테이블 설계
- 엔티티 클래스 개발
- 엔티티 설계시 주의점
요구사항 분석
-
회원
- 회원 등록
- 회원 조회
-
상품
- 상품 등록
- 상품 수정
- 상품 조회
-
주문
- 상품 주문
- 주문 내역 조회
- 주문 취소
-
기타 요구사항
- 상품 재고관리
- 상품의 종류는 도서, 음반, 영화
- 상품은 카테고리로 분류할 수 있다.
도메인 모델
주문과 상품 사이는 다대다 관계 이므로 주문 상품이라는 엔티티를 추가하여 일대다, 다대일 관계로 풀어냈다. 주문 상품 테이블은 관계를 풀어내는 역할 뿐 아니라 주문 상품 개수, 가격 등 필드도 가지고 있다.
엔티티 분석
- status 등 상태는 열거형으로 표현한다.
- Item을 상속받는 Album, Book, Movie가 있다. Item은 Abstract로 구현한다.
- 카테고리는 자식과 부모 카테고리를 가지고 있고 상품과 다대다 관계를 맺는다.
회원이 주문리스트를 가지고 주문도 멤버를 가지는 양방향 참조 형태는
다대일 양방향 연관 관계 예를 위한 상황이다.
실제로는 멤버 테이블의 주문 리스트는 필요 없다.
오히려 Order가 바뀌었을 때 Member의 주문 리스트를 변경해주어야 하므로 어색한 상황이다.
테이블 분석
- 앨범, 도서, 영화 타입을 통합해서 싱글 테이블 타입으로 표현했다.
- 멤버와 배달 엔티티의 Address 임베디드 타입 정보가 테이블에 분해되어 들어갔다.
- 테이블 명이 ORDER가 아니라 ORDERS인 이유는 데이터베이스의 order by 예약어 때문이다.
연관관계 매핑 분석 보기 전에
연관관계 매핑 분석을 보기 전에.. 연관 관계에 대한 사전 지식이 없다면
JPA 연관 관계 한방에 정리
이 글을 읽는 것을 추천한다. 많이 배웠다. 감사합니다.
글에서 기억하면 좋을 것
-
테이블에서는 외래키 하나로 양쪽 테이블 조인이 가능하므로 단방향, 양방향 나눌 필요가 없다.
-
그래서 객체에서만 단방향, 양방향이 나뉜다.
-
양방향 연관 관계의 주인은 무조건 외래키가 있는 곳
-
일대다에서 무조건 다쪽이 외래키를 갖는다.
연관관계 매핑 분석
-
회원과 주문
- 일대다, 다대일 관계이다 양방향 관계다.
- 양방향 관계에서는 연관관계의 주인을 정해야 한다.
- 외래 키가 있는 주문을 연관관계의 주인으로 정하는 것이 좋다.
- 그러므로 Order.member를 ORDERS.MEMBER_ID 외래키와 매핑한다.
-
주문상품과 주문
- 다대일이고, 양쪽 객체에서 서로 참조하는 필드가 있으므로 양방향 관계이다.
- 양방향 관계의 주인은 외래키가 있는 ORDER_ITEM으로 한다.
- 따라서 Order.orderItems 객체를 OrderItem.order로 매핑하고.
- ORDER_ITEM.ORDER_ID 외래키를 ORDER.ORDER_ID로 매핑한다.
-
주문상품과 상품
- 다대일 단방향 관계이다. Order의 Delivery를 ORDERS.DELIVERY_ID 외래키와 매핑.
엔티티 설계시 주의점
-
엔티티에는 가급적 Setter를 사용하지 않는다.
- 유지보수가 어려워진다.
-
모든 연관관계는 지연로딩으로 설정한다!
- 즉시로딩(EAGER)은 예측이 어렵고, 어떤 SQL이 실행될지 추적하지 어렵다.
특히 JPQL을 실행할 때 N+1 문제가 자주 발생한다.
- 즉시로딩(EAGER)은 예측이 어렵고, 어떤 SQL이 실행될지 추적하지 어렵다.
-
컬렉션은 필드에서 초기화 하는 것이 NULL 문제에서 안전하다.
-
하이버네이트는 엔티티를 영속화 할 때, 컬렉션을 감싸서 하이버네이트가 제공하는 내장 컬렉션으로 변경한다.
때문에 임의의 메서드에서 컬렉션을 변경 했다가 하이버네이트 내부 동작에 문제가 발생할 수 있다.
N+1 문제
- 즉시 로딩과 지연 로딩
- N+1 발생 케이스와 해결책
- N+1 문제는 꽤나 심도 있는 내용이다.
- 아직은 너무 자세한 내용 보다는 이게 뭔지, 왜 발생하는지 정도만 이해해도 충분하다.
