인프런 커뮤니티 질문&답변

안녕하세요 영한님.

상속관계 Joined 매핑을 사용할 때, 부모테이블에 대하여 업데이트 쿼리 시 임시 테이블 Create Drop 에 대해 질문드리고 싶습니다.

최근에 플젝을 진행하면서 JPA 상속관계 Joined 전략을 활용했습니다.
부모테이블에 대하여 업데이트 쿼리 시, JPA 구현체가 자체적으로 임시 테이블을 Create 및 Drop 하는 로그를 확인했습니다.

Domain

// 부모 엔티티
@Entity
@DiscriminatorColumn
@Inheritance(strategy = InheritanceType.JOINED)
public class Notification {
	@Id
	@GeneratedValue(strategy = GenerationType.IDENTITY)
	@Column(name = "notification_id")
	private Long id;

	@Enumerated(value = EnumType.STRING)
	@Column(nullable = false, columnDefinition = "varchar(50)")
	private NotificationEventType notificationEventType;

	@Column(nullable = false)
	private LocalDateTime createdAt;

	@Column(name = "\"read\"", nullable = false)
	private Boolean read;

	@ManyToOne(fetch = FetchType.LAZY)
	@JoinColumn(name = "user_id", nullable = false)
	private User notifier;
}

// 자식 엔티티
@Entity
public class RecruitmentNotification extends Notification {

	@ManyToOne(fetch = FetchType.LAZY)
	@JoinColumn(name = "recruitment_id", nullable = false)
	private Recruitment actor;
}

@Entity
public class StudyNotification extends Notification {

	@ManyToOne(fetch = FetchType.LAZY)
	@JoinColumn(name = "study_id", nullable = false)
	private Study actor;
}

@Entity
public class ReviewNotification extends Notification {

	@ManyToOne(fetch = FetchType.LAZY)
	@JoinColumn(name = "review_id", nullable = false)
	private Review actor;
}

Service

@Service
@RequiredArgsConstructor
@Slf4j
public class NotificationCommandService {

	private final NotificationRepositoryImpl notificationRepository;

	public void updateNotificationsAsRead(final User user, final List<Long> notificationIds) {
		notificationRepository.updateNotificationsAsRead(user.getId(), notificationIds);
	}
}

Repository

public interface NotificationJpaRepository extends JpaRepository<Notification, Long> {

	@Modifying
	@Query("UPDATE Notification n "
			+ "SET n.read = true "
			+ "WHERE n.notifier.id = :userId AND n.id IN :notificationIds")
	void updateNotificationsAsRead(final Long userId, final List<Long> notificationIds);

}

@Repository
@RequiredArgsConstructor
public class NotificationRepositoryImpl {

	private final JPAQueryFactory q;
	private final NotificationJpaRepository notificationJpaRepository;
	private final EntityManager em;

	public void updateNotificationsAsRead(final Long userId, final List<Long> notificationIds) {
		notificationJpaRepository.updateNotificationsAsRead(userId, notificationIds);
		em.flush();
		em.clear();
	}
}

업데이트 API를 호출할 때마다, 임시 테이블을 생성하고 드랍하는 행위가 매우 비효율적이라 생각되는데,
이럴 경우 Single 테이블 전략으로 수정하거나, 상속관계 매핑 자체를 안쓰는 방법밖엔 없을까요?

상속관계 매핑 전략은 애플리케이션 레벨에서 DB 테이블의 조작을 손쉽게하는 장점이 있긴하지만,
결국 상용 서비스 중인 DB를 세팅할 땐 데이터베이스 레벨에서 DDL을 직접 세팅하는게 좋고, 기존의 장점이 상쇄되는 느낌입니다.

성능적 손해를 감수하면서도 상속 관계 매핑을 활용하는게 좋은 접근 방법인지 판단이 서지 않아 질문드립니다 🙂