회원은 여러 주문을 하고
주문 할때 여러개 주문 한다. 하지만 상품하고 다대다 관계가 되기 때문에.
중간에 주문상품 엔티티를 만들어 주문 주문상품 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도
하이버네이트가 추적하기위해 퍼시스 어쩌구로 바꾸는듯..
컬렉션은 변경하면 안됌..
결론적으론 ?
카멜케이스 , 점 -> 언더 스코어
대문자 -> 소문자
원래는 이렇게 해야되지만
이 두개를 원자적으로 묶는 방법으로
양방향 ..