7장 고급 매핑

[MinJunKweon]

끄적끄적

• 슈퍼타입 / 서브타입 관계 모델링이 필요한 요구사항은 개발할 때 예상했던 것보다 많이 있었음
• 하지만, 개인적인 생각으로는 엔티티라면 상속을 사용하지 않고, 각각 개별로 관리하는 편이 좋은 것 같음. (실제로 회사 프로젝트에서도 개별 테이블, 개별 엔티티로 관리 중)
• 요구사항을 예측했을 때, 여러 엔티티가 공통으로 변경되어야 하는 경우가 잦은 경우라면 고려해볼만 한듯. (그래도 개별로 관리하는 편이 좋다고 생각함)
• @MappedSuperclass는 생성시간, 수정시간 같은 Audit을 위한 필드를 강제하기 위해 사용하면 좋다고 생각함
• 챕터 6과 겹치는 부분이 많아서 쓸게 많이 없네요

[minkukjo]

끄적 끄적

• 한 번도 사용해본적은 없지만, JPA에서 상속을 지원해주는 애노테이션이 있다고 한다.

  • @Inheritance(strategy = InheritanceType.JOINED) : 상속 매핑은 부모에 이 애노테이션을 달아주어야한다. 전략이 여러 개 존재함.
  • @DiscriminatorColumn(name = "DTYPE") : 부모 클래스에 구분자 컬럼을 지정한다. 기본값은 DTYPE
  • @DiscriminatorValue("M") : 엔터티를 저장할 때 구분 컬럼에 입력할 값을 저장한다. 자식 테이블에 이 값을 넣으면 부모가 가진 컬럼에 이 값이 들어감.
  • InheritanceType.SINGLE_TABLE : 단일 테이블 전략을 씀. 하나에 다 때려박는다.
  • 위 타입에선 구분 컬럼이 필수다.
  • InheritanceType.TABLE_PER_CLASS : 구현 클래스 마다 테이블 전략인데, 이 방법은 선호되지 않으므로 가급적 쓰지 말자.

• @MappedSuperClass : 좋은 기능이긴 하나, 실무에서 쓰긴 조금 애매할 수 있음.

• 복합키 사용을 위해 JPA에선 두 가지 방법을 제공해준다. 하나는 @IdClass이고, 다른 하나는 EmbeddedId이다. ( 우리팀에선 후자를 주로 쓰고 있음 )

• 개인적으로 책을 읽어보니, IdClass보다는 EmbeddedId가 조금 더 명확해보여서 마음에 든다.

• 저자 또한 둘은 각각 장,단점이 있으니 취향에 맞게 일관성있게 사용할 것을 추천하고 있다.

궁금한 점

• 저자는 식별/비식별에서 비식별 관계를 쓰고, Long 타입을 추천하고 있음.
• 이 의견에 대해 다른 분들 생각은 어떠하신지 궁금.

[LOG-INFO]

• 상속 관계 매핑
  • 조인 전략
  • 부모 테이블의 row수가 많아질 수도 있음
  • 매번 조인을 해야하니 성능면에선 떨어짐
  • 단일 테이블 전략
  • 너무 테이블이 커지고, nullable 필드가 너무 많아짐...
  • 한 테이블의 row수가 많아질 수도 있음
  • 근데 단일테이블이라 관리는 쉬울 듯
  • 구현 클래스마다 테이블 전략
  • 한 테이블의 row수는 줄어들 듯 (sharding 느낌)
• @EmbeddedId 오늘 사이드프로젝트에 써봤는데, 한 뎁스 들어가는게 불편해서 @IdClass로 다시 바꿈

[HaeUlNam]

끄적끄적

• 상속관계 매핑: 객체는 상속 관계가 존재, RDB에는 상속 관계 존재 X
  • 슈퍼 타입 서브 타입 관계라는 모델링 기법이 객체 상속과 유사
  • 상속 관계 매핑: 객체의 상속 구조와 DB의 슈퍼 타입 서브 타입 관계를 매핑

• 구현 전략

  • Join 전략: table은 분리하되 PK로 Join을 하고, DType으로 구분한다.

    • Entity에 @DiscriminatorColumn을 넣으면, Entity이 name이 들어간다.
    • 장점
      • 테이블 정규화
      • 외래 키 참조 무결성 제약조건 활용 가능
      • 저장 공간 효율화
    • 단점
      • 조회 시 조인을 많이 사용, 성능 저하 가능
      • 조회 쿼리가 복잡함
      • 데이터 저장시 Insert query 2번

    → 사실 조인 이나 insert query 2번 나가는 건 그렇게 성능 저하가 일어나지는 않음. 복잡한 게 더 문제..

  • 단일 테이블 전략: 하나의 테이블에 모든 요소를 넣는다

    • 장점
      • 조회 쿼리 단순화
      • Join이 필요없으므로 일반적으로 조회 성능이 좋다.
    • 단점
      • 자식 엔테티가 매핑한 컬럼은 모두 Null
      • 단일 테이블에 모든 것을 저장하기에 테이블이 커질 수 있고, 상황에 따라 조회 성능이 오히려 느려질 수 있다.

  • 구현 클래스마다 테이블 전략: 모든 컬럼을 테이블이 각각 다 가진다.

    • 이 전략은 DB 설계자와 ORM 전문가 모두 추천 X
    • 단점
      • 여러 테이블을 함께 조회할 때 성능이 느림(UNION SQL)
• MappedSuperClass: 엔티티가 공통으로 사용하는 매핑 정보를 모으는 역할. 전체 엔티티에서 공통으로 적용하는 정보를 모을 때 사용 e.g. BaseEntity

더 알아본 내용

• JPA Entity composition vs inheritance
  • Plain Java class에서 composition을 쓰라고 한것처럼 Entity도 동일하다.
  • JPA Entity composition을 사용하면 inheritance mapping에 있어서 단점들(e.g. 성능 이슈, 데이터 일관성)을 가져가지 않을 수 있다.
  • JPA Entity composition을 구현하는 방법
    • @Embeddable annotation을 이용
    • Mapping(e.g. ManyToOne등등)을 통해 독립적으로 관리 - 각 Entity가 database table에 mapping되고, 독립적으로 로딩
  • https://thorben-janssen.com/composition-vs-inheritance-jpa-hibernate/