[Project] 좋아요 구현에 대하여

📌 개인적인 공간으로 공부를 기록하고 복습하기 위해 사용하는 블로그입니다.
정확하지 않은 정보가 있을 수 있으니 참고바랍니다 :😸
[틀린 내용은 댓글로 남겨주시면 복받으실거에요]

---

이번 프로젝트에서 좋아요 기능을 구현해야 했는데, 게시글, 댓글, 이미지 게임, 밸런스 게임 등 다양한 요소에 대해 좋아요를 처리해야 해서 처음엔 꽤 복잡한 연관관계가 고민됐다. 그래서 상속을 이용해 구현하는 방법을 먼저 생각해봤다.

상속으로 구현

SINGLE_TABLE 전략

SINGLE_TABLE 전략은 상위 클래스와 하위 클래스의 모든 속성을 하나의 테이블에 저장하는 방식이다. 이 전략을 사용하면 모든 데이터가 하나의 테이블에 모이기 때문에 구조가 단순해진다.

1. 특징
   • 하나의 테이블에 모든 속성이 포함된다.
   • 상위 클래스와 하위 클래스 간의 식별을 위해 식별자 컬럼이 자동으로 생성된다.
2. 장점
   • 단순한 쿼리: 모든 데이터가 하나의 테이블에 있어서 조회할 때 복잡한 조인 없이 데이터를 가져올 수 있다.
   • 빠른 성능: 조인이 필요 없기 때문에 조회 성능이 좋을 수 있다.
3. 단점
   • 테이블 크기 증가: 모든 데이터를 하나의 테이블에 저장하므로 테이블 크기가 커질 수 있다.
   • NULL 값 증가: 특정 하위 클래스에만 해당하는 필드들이 다른 클래스에서는 NULL로 저장되기 때문에, 공간이 비효율적으로 사용될 수 있다.

4. 예시

   실제로 구현했을때는 아래와 같은 테이블이 생성된다.

   HEART_ID	MEMBER_ID	POST_ID	COMMENT_ID	HEART_TYPE
   1	10	100	NULL	PostHeart
   2	20	NULL	200	CommentHeart

JOINED 전략

JOINED 전략은 상위 클래스와 하위 클래스가 각각 별도의 테이블에 저장되는 방식이다. 이 방식은 데이터가 정규화되어 테이블의 크기가 작아지고, 각 클래스가 독립적인 테이블을 가지게 된다.

1. 특징
   • 상위 클래스의 속성을 저장하는 여러 테이블이 생성된다.
   • 하위 클래스의 데이터를 조회할 때는 조인이 필요하다.
2. 장점
   • 데이터 정규화: 데이터가 정규화되어 테이블 크기가 작아진다.
   • 명확한 구조: 각 클래스의 데이터가 독립적인 테이블에 저장되므로, 구조가 명확하다.
3. 단점
   • 복잡한 쿼리: 데이터를 조회할 때 조인이 필요해서 쿼리가 복잡해질 수 있다.
   • 삽입 성능 저하: 여러 테이블에 데이터를 나눠서 저장해야 하므로 성능이 저하될 수 있다

상속 대신 단일 클래스로 구현

처음에는 상속을 통해 복잡한 연관관계를 해결하려 했지만, 결국 단일 클래스로 구현하는 것이 더 간단하고 효율적이라는 결론을 내렸다. 상속 구조는 장점도 있지만, 오히려 복잡성을 더할 수 있었기 때문이다.

그래서 단일 클래스로 Like 엔티티를 아래와 같이 구현했다:

java코드 복사
@Entity
public class Like {
    @Id
    @GeneratedValue(strategy = GenerationType.IDENTITY)
    private Long id;

    private Long memberId;

    private Long contentId;

    @Enumerated(EnumType.STRING)
    private ContentType contentType;

    public enum ContentType {
        POST, COMMENT, BALANCE_GAME, IMAGE_GAME
    }
}

이렇게 구현하면 Like 엔티티 하나로 게시글, 댓글, 이미지 게임, 밸런스 게임 등 다양한 컨텐츠에 대한 좋아요를 관리할 수 있다.
ContentType enum을 사용해 어떤 타입의 컨텐츠인지 구분할 수 있도록 했고, 덕분에 코드가 훨씬 단순해지면서도 확장성도 확보할 수 있었다.

결과적으로, 이번 프로젝트에서는 상속보다는 단일 클래스로 구현하는 것이 더 적합했다.
계속 구현 방법에 대해서 생각해보았는데 상속을 할거면 전체를 board로 엮어서 상속을 받은 다음 댓글이나 좋아요를 관계 매핑 한는게 맞는 것 같고
제네릭도 생각해봤는데 찾아보니 제네릭은 애초에 JPA에서 지원하지 않는 타입이라고 한다.
그것도 당연한게 어떤 타입이 올지 모르는데 그게 엔티티로 만들어지는 것도 말도 안되는 일이다.
최종적으로 좋아요를 구현하는데 있어서는 enum으로 타입을 받는 것이 맞다고 생각했다.
여러 컨텐츠 타입을 하나의 엔티티로 관리하면서 필요한 기능을 충분히 담을 수 있었고, 단순하면서도 확장 가능한 구조를 갖출 수 있었다.

Project 카테고리 내 다른 글 보러가기