2.요구사항 분석 설계

 

1. 도메인 모델과 테이블 설계

 

• 회원 엔티티 분석

 

• 회원 테이블 분석

*  연관관계의 매핑 분석 -> 참고: 외래 키가 있는 곳을 연관관계의 주인으로 정해라.

• 회원과 주문 : 일대다, 다대일의 양방향 관계
  • 외래키가 있는 주문 을 연관관계의 주인으로 하는 것이 좋다. 그러므로 Order.member 를 ORDERS.MEMBER_ID 외래키와 매핑한다. 
• 주문상품과 주문 : 다대일 양방향 관계다. 외래 키가 주문상품에 있으므로 주문상품이 연관관계의 주인이다.
  • 그러므로 OrderItem.order를 ORDER_ITEM.ORDER_ID 외래키와 매핑한다.
• 주문상품과 상품: 다대일 양방향 관계다. OrderItem.item 을 ORDERITEM.ITEM_ID 외래 키와 매핑한다.
• 주문과 배송 : 일대일 양방향 관계다. Order.delivery를 ORDERS.DELIVER_ID 외래키와 매핑한다.
• 카테고리와 상품 : @ManyToMany 를 사용해서 매핑한다. ( 실무에서는 @ManyToMany는 사용하지 말자)

 

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

 

• 엔티티 설계 시 주의 점 
  • 엔티티에는 Setter을 사용하지 말자. 변경포인트가 많아서, 유지보수가 어려워진다.
  • 모든 연관관계에는 자연로딩으로 설정한다.  (매우매우 중요!)
    • 즉시로딩은 예측이 어렵고, 어떤 SQL 이 실행될지 파악하기가 너무 어렵다.  JPQL을 사용할때 N+1 문제가 자주 발생한다.
    • 실무에서 모든 연관관계는 지연로딩 (LAZY) 로 설정해야 한다.
    • OneToOne, ManyToOne 는 기본 fetch전략이 fetch= FetchType.LAZY 로 다 바꿔줘야한다!
  • 스프링 부트 신규 설정 (엔티티(필드) 테이블(컬럼))
    
    • 카멜 케이스 ->  언더스코어 ( Ex. memberPoint ->  member_point)
    •  .(점) ->  _(언더스코어)
    • 대문자  -> 소문자
  • Cascade

 

 

* 연관관계 메서드

setMember : Member 을 저장하고, Order을 저장한다. 
addOrderItem : OrderItem 을 저장하고, Order을 저장한다.