View Table + JPA 매핑

View Table

: 데이터가 아닌 SQL 을 저장하고 있는, 보여주는 것 만을 목적으로 하는 테이블

-> 따라서 원본 테이블의 데이터가 변경되면 뷰 테이블에도 해당 변경 사항이 즉시 반영됨

 

 

장점

: 다른 쿼리나 뷰에서 재사용이 가능하기 때문에 개발 생산성 향상

  -> 반복적인 작업이나 복잡한 쿼리의 경우 View Table을 사용하는 것이 효율적

 

단점

: 뷰 테이블 생성 이후 수정 어려움 

-> 삭제 후 다시 만들면 됨, 어차피 뷰 테이블은 가상 테이블이니 타격 X

 

 

 

현재 회사 프로젝트에서 View Table을 만드려는 이유

 

: Admin

 

Admin 역할 특성 상, 모든 회사 스키마의 값을 조회하는 경우 많음

이경우, 다중 스키마의 테이블을 하나의 엔티티로 ORM 매핑하는 것은 어려움

 

Client의 경우 하나의 스키마를 바라보기 때문에
데이터소스에서 스키마를 변경하면 변경된 스키마 내 같은 이름의 테이블과 자동으로 매핑 됨

 
하지만 Admin은 여러 스키마의 값을 동시에 봐야하기 때문에 해당 방식이 불가능

 

 

따라서 프로시저를 이용해서 각 스키마를 Select하고, Union All로 합쳐서 뷰 테이블로 따로 만드는 것이 가독성과 유지 보수성 향상에 좋다고 판단

 

-> 그리고 회사 시스템 상 동적으로 스키마가 늘어나기 때문에 코드상에선 해결할 수 가 없었다..

백엔드 서버를 내리고 스키마가 추가될 때마다 코드를 수정하고 다시 백엔드서버를 올릴 수는 없으니..

 

-> 이후 별개의 View Entity + Spring data JPA로 매핑하여 관리

 

 

매핑 방식

 

Entity

 

1. 가상 뷰 생성 후 @Table로 매핑 + @Immutable로 불변 객체 만들기

@Entity
@Getter
@Table(name = "admin_project_vew")
@Immutable
public class AdminProjectView

2. @Subselect로 매핑 + @Immutable로 불변 객체 만들기

@Entity
@Getter
@Immutable
@Subselect("SELECT * FROM schema1.project" 
	+ " UNION ALL "
    + " SELECT * FROM schema2.project")
public class AdminProjectView

 

Repository

public interface AdminProjcetViewRepository extends JpaRepository<AdminProjectView, Long>

 

-> findById 같은 쿼리 메소드 단건 조회부터 연관관계 매핑된 것까지 정상 작동 확인

 

 

 

궁금증1

@Table과 @Subselect를 동시에 사용하면 어떤게 우선시 될지

 

당연 @Subselect!! 

 

@Table로 매핑한 테이블이 무시되고 @Subselect가 우선시 된다.

 

 

궁금증2

AdminProjectView 객체를 만들어서

AdminProjectViewRepostory의 save() 메소드로 저장한다면 어떻게 될까?

 

당연 예외가 터진다!