[자바 ORM 표준 JPA 프로그래밍 - 기본편] JPA 소개(1)

이재표·2023년 9월 12일

JPA

자바 ORM 표준 JPA 프로그래밍 - 기본편

목록 보기

1/15

SQL 중심적인 개발의 문제점

애플리케이션 개발 -> JAVA(객체)
데이터베이스 -> SQL(관계형 DB)

데이터베이스와 어플리케이션간의 패러다임의 불일치로 여러 문제가 생김

SQL 중심적인 개발의 문제점

다양한 DB가 있지만 현실적인 대안으로 관계형DB를 이용하기 때문에 sql에 의존적인 개발을 피할수가 없다.

자바 객체를 sql로, sql을 자바 객체로 매핑하는 과정을 개발자가 "직접" 작업해야하기에 "불편"하고 "잦은 실수"가 발생할수 있다.

패러다임의 차이

자바는 상속의 개념이 존재하여, 변리하게 부모클래스의 필드를 사용할수 있지만, 데이터베이스에는 객체의 상속관계가 없다.

상속 : 부모클래스의 필드,메서드를 자식클래스에서 물려주면서 중복된 코드를 줄이고, 유지 보수가 편리하며, 통일성이 있고 다형성을 구현할수 있게된다.
다형성 : 상위 클래스가 동일한 메시지로 하위 클래스들을 다르게 작동시키는 객체지향원리

데이터베이스에는 상속의 개념이 없기때문에 슈퍼타입 서브타입관계(FK이용)를 통해 표현은 가능하지만 같게 기능하진 못한다..
따라서 다음과 같이 객체를 저장 및 조회하게 된다.

저장
Album을 저장하고싶다면, Album,Item테이블에 각각 값을 넣어줘야한다.
1. 어플리케이션단에서 객체를 분리
2. 테이블에 각각 Insert해준다.

조회
1. Item과 Album은 각각 다른 테이블이기에 FK를 통해 Join하여 한번에 데이터를 가져와야함(각각 가져오면 성능상 좋지못함)
2. 어플리케이션 단에서 Item객체, Album객체를 각각 만들어준다.
3. 객체에 테이블에서 가져온 데이터를 넣어준다.
4. 만약 MOVIE나 BOOK을 조회한다면 다시 ITEM과 함께 JOIN해서 조회해야함(모든 것을 개발자가 진행해야함)

만약 자바 컬렉션을 이용한다면..?

저장

LIST.ADD(ALBUM);

조회

ALBUM album=list.get(albumId);

다형성 이용도 가능
Item item=list.get(albumId);

패러다임이 일치한다면 매우 쉽게 상속관계를 표현할수 있다.

그렇다면 연관관계는?

객체는 참조를 이용하여 연관된 객체를 꺼내올수있다 : member.getTeam()
테이블은 외래키를 이용하여 연관관계를 사용 : JOIN ON M.TEAM_ID=T.TEAM_ID

데이터베이스에는 참조개념이 없기에 오직 FK를 통해 Join하여 연관관계를 맺게됨
그 결과 객체를 객체답게가 아닌 데이터베이스에 맞춰 모델링하게됨

쿼리를 만들때 FK를 이용해야하기에 객체일지라도 참조를 이용하지 않고 ID(FK)를 저장

SQL을 이용해도 객체스럽게 만들수는 없을까?

가능하다! 하지만 SQL쿼리를 짤때 굉장히 복잡해진다.

Team에 대한 참조만 있고 id는 없기때문에 곤란하다. Member에서 Team 을 get메서드로 꺼낸후 Team의 Id까지 get메서드로 꺼내면 fk를 알수있지만 복잡하다...

조회도 객체스럽게 가능하다 하지만 복잡하다..

db테이블에서 Member, Team테이블을 Join하여 한번에 조회한다.

Member, Team객체를 생성하여 데이터를 주입하고, 연관관계를 설정한다.

그렇다면 객체지향 패러다임으로 데이터를 관리하면?

list.add(member);
Member member = list.get(memberId);
Team team = member.getTeam();

Member와 Team이 연관관계가 걸려있는 상태에서, 한 객체를 리스트에 add하면 연관관계가 걸려있는 상태 그대로 삽입되게 됨

Member와 Team을 조회하는 쿼리이기에 조회하지 않은 Order는 null이 나오게된다.

계층형 아키텍쳐는 참조한 객체를 믿고 쓸수 있어야하는데, 조회한 쿼리만 이용되는 관계형 db에서는 신뢰가 불가능.

메서드 안을 확인해서 어떤 쿼리가 사용됬는지 확인이 필수적임