도메인 모델과 테이블 설계

회원 엔티티

→ N:N 인 다:다 관계는 상당히 안좋기 때문에, 1:N 관계로 바꿔줘야한다.

카테고리와 아이템의 관계를 보면, 컬렉션을 가지게 된다면 이제 다 되는 거니까 양쪽 다 컬렉션을 가지고 N:N관계를 만들 수 있따.(객체일 경우) 그런데, 관계형 데이터베이스는 일반적인 설계로는 이게 절대 안되는 것이다. 그래서 중간에 카테고리_아이템이라는 매핑 테이블을 두고 이걸로 카테고리 아이템의 N:N 관계를 1:N 관계로 풀어냈다.(아래 회원테이블 확인)

회원 테이블

상속관계 매핑 기본편에서 설명한 3가지 방법을 쓴 테이블 구조이다.

연관관계 매핑 분석

• **회원과 주문:**일대다 , 다대일의 양방향 관계다. 따라서 연관관계의 주인을 정해야 하는데, 외래 키가 있는 주문을 연관관계의 주인으로 정하는 것이 좋다. 그러므로 Order.member 를 ORDERS.MEMBER_ID 외래 키와 매핑한다.
• **주문상품과 주문:**다대일 양방향 관계다. 외래 키가 주문상품에 있으므로 주문상품이 연관관계의 주인이다. 그러므로 OrderItem.order 를 ORDER_ITEM.ORDER_ID 외래 키와 매핑한다.
• 주문상품과 상품: 다대일 단방향 관계다. OrderItem.item 을 ORDER_ITEM.ITEM_ID 외래 키와 매핑한다.
• 주문과 배송: 일대일 양방향 관계다. Order.delivery 를 ORDERS.DELIVERY_ID 외래 키와 매핑한다.
• 카테고리와 상품: @ManyToMany 를 사용해서 매핑한다.(실무에서 @ManyToMany는 사용하지 말자. 여기서는 다대다 관계를 예제로 보여주기 위해 추가했을 뿐이다)

<aside> ❗ 참고: 외래 키가 있는 곳을 연관관계의 주인으로 정해라. 연관관계의 주인은 단순히 외래 키를 누가 관리하냐의 문제이지 비즈니스상 우위에 있다고 주인으로 정하면 안된다.. 예를 들어서 자동차와 바퀴가 있으면, 일대다 관계에서 항상 다쪽에 외래 키가 있으므로 외래 키가 있는 바퀴를 연관관계의 주인으로 정하면 된다. 물론 자동차를 연관관계의 주인으로 정하는 것이 불가능 한 것은 아니지만, 자동차를 연관관계의 주인으로 정하면 자동차가 관리하지 않는 바퀴 테이블의 외래 키 값이 업데이트 되므로 관리와 유지보수가 어렵고, 추가적으로 별도의 업데이트 쿼리가 발생하는 성능 문제도 있다. 자세한 내용은 JPA 기본편을 참고하자.

</aside>

→ 즉, 외래키가 가까운 곳에 있는 것을 연관관계 주인으로 잡는다. 그래야 모든 것이 편하다.

엔티티 클래스 개발

예제에서는 설명을 쉽게하기 위해 엔티티 클래스에 Getter, Setter를 모두 열고, 최대한 단순하게 설계 실무에서는 가급적 Getter는 열어두고, Setter는 꼭 필요한 경우에만 사용하는 것을 추천