도메인 분석 설계
요구사항 분석
회원은 여러 주문을 하고
주문 할때 여러개 주문 한다. 하지만 상품하고 다대다 관계가 되기 때문에.
중간에 주문상품 엔티티를 만들어 주문 주문상품 1:다 주문상품 상품 *:1 관계를
만들어 준다.
상품 분류는 상속관계로 풀 수 있다.
회원 엔티티 분석
회원 :이름 임베디드 타입 / 주문 리스트 가짐
설계 단계에선 양방향 보단 단방향이 좋음
ex) 주문이 생성할때 회원이 필요하다
회원 테이블 분석
ITEM 싱글테이블 전략 (단순한)
연관관계 매핑 분석
일대다, 다대일 양방향 관계에서 주인을 정할때
외래키가 연관관계의 주인이 되는게 좋다
OrderItem -> Item
단방향
왜 ? Item에서 나를 주문한것을 모두찾아 이런게 없기 때문에
엔티티 클래스 개발
JPA 는 Member / Orders 둘 중 외래키 업데이트는 누가하지?
테이블은 외래키 하나만 변경하면 되는대 둘중의 하나를 주인이란 개념으로..
(연관관계 주인)
내 테이블안에 있는거를 바꾸는게 쉬우니 Orders 주인.
다대다 매핑은 추천하지않는 이유는 확장도 안돼고..
Ex) 수정일자 이런거..
이 부분은 복습 부분 JPA 활용을 듣고 다시 복습하자
엔티티 설계시 주의점
가급적 Seeter 사용하지말자
변경 포인트가 너무 많아서 유지보수가 어려움..
모든 연관관계는 지연로딩으로 설정!
즉시로딩(EAGER) 예측이 어렵다, 어떤 SQL 실행될지 추적 어려움
특히 JPQL 실행할때 N+1 문제가 자주 발생
실무에선 모든 연간관계는 지연 로딩으로..
ex) EAGER 해놓으면 오더를 조회할때 멤버를 다 조회함?
selete o from order o; ->>SQL select * from order -> n+1
Order 백번조회하면 멤버 조회 쿼리 100개 더 들어감.
오더를 조회하는 시점에서 멤버를 무조건 조회하겠다..
@ManyToOne -> EAGER / @OneToMany -> LAZY
//이건 다 레이지로 바꿔주자
+@OneToOne도
하이버네이트가 추적하기위해 퍼시스 어쩌구로 바꾸는듯..
컬렉션은 변경하면 안됌..
테이블 컬럼명 생성 전략
결론적으론 ?
카멜케이스 , 점 -> 언더 스코어
대문자 -> 소문자
원래는 이렇게 해야되지만
이 두개를 원자적으로 묶는 방법으로
양방향 ..
