엔티티 설계 주의점

1.엔티티에는 가급적 Setter를 사용X.

Setter가 모두 열려있으면 변경포인트가 많아서 유지보수가 어렵다.

 

2.모든 연관관계는 지연로딩으로 설정.

즉시로딩(EAGER)는 예측이 어렵고, 어떤 SQL이 실행될지 추적이 어렵다.

실무에서는 모든 연관관계는 지연로딩(LAZY)로 설정.

연관된 엔티티를 함께 DB에서 조회해야 하면, fetch join 이나 엔티티 그래프 기능을 사용한다.

OneToOne,ManyToOne 관계는 기본이 즉시로딩이므로 직접 지연로딩으로 설정.

 

ex)JPQL select o From order o; ->SQL select* from order의 경우 100 + 1(order)

select조회시 Order가 100개인 경우 100의 쿼리가 추가로 발생함. (N+1 문제가 자주 발생함) 

 

3.컬렉션은 필드에 초기화하자.

하이버네이트가 엔티티를 영속화 할 때, 컬렉션을 감싸서 하이버네이트가 제공하는 내장 컬렉션으로 변경됨.

만약 getOrders()처럼 임의의 메서드에서 컬렉션을 잘못 생성하면 하이버네이트 내부 매커니즘에 문제가 발생할 수 있다. 따라서 필드에서 초기화하는것이 가장 안전함.

ex)

Member member = new Member();

System.out.println(member.getOrders().getClass());

em.persist(team);

System.out.println(member.getOrders().getClass());

//출력 결과

class java.util.ArrayList

class org.hibernate.collection.internal.PersistentBag

 

4.테이블,컬럼명 생성 전략

스프링 부트의 경우(엔티티 -> 테이블)

1.memberPoint->member_point

2. .(점) -> _(언더스코어)

3. 대문자 -> 소문자 

 

바꾸고 싶으면 

논리명: 명시적 컬럼,테이블명 안적을때 적용.

spring.jpa.hibernate.naming.implicit-strategy 

물리명(명시를해도 규칙을 준수)

spring.jpa.hibernate.naming.physical-strategy 변경.

 

4.cascade=CascadeType.ALL

persist를 전파하는 기능.delete할때도 같이 지워버림. 모든엔티티는 기본적으로 퍼시스트를 저장하고싶으면 각자해줘야됨.

ex)

persist(orderItemA)

persist(orderItemB)

persist(orderItemC)

persist(order)

->

persist(order)