Hibernate JPA에서 상속 구조는 어떻게 표현할 수 있을까?

나만의 옷장 서비스에 Entity인 Wardrobe(옷장), Cloth(옷),  Record(코디)는 댓글이 달릴 수 있고, 좋아요가 눌릴 수 있는 동일한 특징을 가지고 있다. 그래서 Entity인 Like(좋아요)와 Comment(댓글)에 Wardrobe, Cloth, Record가 속성으로 모두 포함하고 Wardrobe, Cloth, Record 각각에 모두 Like와 Comment를  포함하는 식으로 구현을 하였다. 

 

물론 기능은 정상 동작하지만 과연 이 방법 밖에 없는 것인가 의문이 생겼다. 이런식으로 구현하게 되면 중복 코드가 굉장히 많아지고 또 동일한 특징을 가진 Entity가 추가 되면 Comment와 Like와 관련된 로직을 또 다시 작성해야 하는 상황이 발생하게 된다. 이렇게 되면 굳이 Hibernate를 사용한 의미가 없지 않을까? 

 

Hibernate에서 엔티티들의 상속 관계를 나타낼 수 있는 방법이 있지 않을까? 라는 생각이 들어 한번 찾아보았다. 그 결과 Hibernate 상속 전략이라는 것을 찾아볼 수 있었다. 

 

Hibernate 상속 전략

관계형 데이터베이스에는 상속 개념이 존재하지 않지만 슈퍼 타입과 서브 타입이라는 관계가 존재한다. 슈퍼 타입은  서브 타입들을 일반화한 Table이며 서브 타입은 슈퍼 타입을 좀 더 구체화한 Table이라고 할 수 있다.  Hibernate는 이러한 관계를 객체 지향적인 상속 관계로 구현할 수 있는 방법을 제공하는데 이것이 바로 상속 전략이다. 상속 전략에는 총 3가지가 존재하는데 한번 알아보도록 하자.

 

SINGLE TABLE 전략 

@Inheritance(strategy = InheritanceType.SINGLE_TABLE)
public class PostEntity extends BaseTimeEntity {

    @Id
    @GeneratedValue(strategy = GenerationType.IDENTITY)
    private Long id;
    
    ...
    
 }

PostEntity의 서브 타입인 모든 엔티티들을 하나의 테이블로 관리하는 상속 전략이다. 조인이 발생하지 않으며 데이터를 변경할 때 한번의 쿼리만 날리게 된다.  하나의 테이블에 모든 속성을 관리하기 때문에 구분을 위해 DType이 필수로 필요하다. 만약에 @DiscriminatorColumn을 지정하지 않아도 기본적으로 DType 컬럼이 생성된다.

 

@DiscriminatorColumn : 부모 클래스에 선언하며, 자식들을 구분하는 용도의 컬럼, default = DTYPE이다. 
@DiscriminatorValue("") : 하위 클래스에 선언하며, 구분 컬럼에 어떤 값을 지정할지 설정한다. default = 클래스 이름이다. 

 

JOINED 전략 

@Inheritance(strategy = InheritanceType.JOINED)
public class PostEntity extends BaseTimeEntity {

    @Id
    @GeneratedValue(strategy = GenerationType.IDENTITY)
    private Long id;
    
    ...
}

슈퍼 타입인 엔티티와 서브 타입인 엔티티들을 조인을 이용하여 관리하는 상속 전략이다. 조인은 id 속성을 통해 발생하기 때문에 서브 타입과 슈퍼 타입이 동일하게 id 속성을 가지고 있어야 한다. 따라서 데이터를 변경이 발생하는 경우 다음과 같이 슈퍼 타입 엔티티와 서브 타입인 엔티티에 총 2번의 쿼리를 날리게 된다.  (dtype이 바로 구분을 위한 구분자이다!) 

insert into post_entity (created_date, modified_date, image_id, like_cnt, member_id, dtype) values ('2021-09-17T23:20:54.135+0900', '2021-09-17T23:20:54.135+0900', 1, 0, 1, 'Wardrobe');
Hibernate: 
    insert 
    into
        wardrobes
        (is_public, name, post_id) 
    values
        (?, ?, ?)

 

TABLE_PER_CLASS 전략

@Inheritance(strategy = InheritanceType.TABLE_PER_CLASS)
public abstract class PostEntity extends BaseTimeEntity {

    @Id
    @GeneratedValue(strategy = GenerationType.IDENTITY)
    private Long id;
    
    ...
    
}

조인 전략과 유사하게 테이블을 따로 관리하지만 슈퍼 타입의 속성들이 서브 타입으로 내려가 위치한다. JOIN, SINGLE TABLE 전략과 다르게 공통 속성이 중복된다는 차이점이 있다. 그리고 TABLE_PER_CLASS에서는 슈퍼 타입 엔티티가 물리적으로 존재하는 테이블이 아니므로 추상 클래스로 선언하는 것이 권장된다. (생성이 불가능하기 때문) 

 

여기서 그런데 문제가 하나 발생한다. TABLE_PER_CLASS 전략은 각각 테이블이 id를 가지고 있기 때문에 단순히 GenerationType.IDENTITY 전략을 이용하여 id를 생성하게 되면 슈퍼 타입 엔티티를 이용하여 서브 타입 엔티티에 접근했을 때 충돌이 발생한다.  왜냐하면 GenerationType.IDENTITY 전략은 데이터베이스에 키 생성을 맡겨 진행하기 때문에 각각 엔티티에 존재하는 id 속성들이 유니크 하지 않기 때문이다.

따라서 id 속성을 유니크하게 유지할 수 있는 GenerationType.TABLE 전략을 사용해야 한다. GenerationType.TABLE 전략은 키 생성 전용 테이블을 하나 만들어서 데이터베이스 시퀀스를 흉내내는 전략인데 서브 타입 엔티티들이 동일하게 이 테이블을 사용하도록 설정함으로서 유니크하게 유지할 수 있기 때문이다. 

 

그런데 TABLE_PER_CLASS는 슈퍼 타입 엔티티로 검색을 할 경우 서브 타입 테이블들을 모두 UNION하여 조회하기 때문에 성능상 좋지 못하다. 따라서 권장하는 방법은 아니라고 한다. 키 생성 전략에 대해 궁금하다면 아래 링크에서 자세히 알아보자!

 

https://gmlwjd9405.github.io/2019/08/12/primary-key-mapping.html

[JPA] 기본키(PK) 매핑 방법 및 생성 전략 - Heee's Development Blog

 

위와 같이 상속 전략을 이용하여 상속 관계를 구현하게 되면 좀 더 좋은 코드를 작성할 수 있다. 예를 들어서 공통 비즈니스 로직들을 하나의 서비스로 따로 모아서 관리할 수 있기 때문에 중복 로직이 대폭 줄어들며 그 뿐만 아니라 슈퍼 타입을 상속받기만 한다면 그 엔티티를 위한 공통 비즈니스 로직을 사용할 수 있어 확장성에도 아주 용이하다.