인프런 - 자바 ORM 표준 JPA 프로그래밍 - 기본편 강의노트
보통 애플리케이션을 개발할 때는 객체 지향 언어로 개발한다.(Java, Python, Scala, ...)
데이터베이스를 사용할 때는 보통 관계형 DB를 많이 사용한다. NoSQL은 부가적으로 사용하는 경우가 많다.
그러면 객체를 관계형 데이터베이스에 저장하는 것이 필수적인 작업이다.
객체를 관계형 데이터베이스에 저장하려면 SQL을 이용하여 저장하여야 한다.
SQL 중심적인 개발의 문제점
SQL을 이용하여 저장할 때, 한 객체에서 필드 하나만 추가 되어도 쿼리 문이 많이 복잡해진다.
객체와 관계형 데이터베이스는 비슷하면서도 다르다.
1. 상속
Table 슈퍼타입 서브타입 관계 -> 부모의 ID를 PK, FK로 가져와서 필요할때마다 Join해서 쓴다.
조회할 때? 슈퍼타입과 서브타입을 Join해줘야 한다. -> 복잡하다.
-> 그래서 DB에 저장할 객체에는 상속 관계를 쓰지 않는다.
2. 연관관계
Member가 Team을 가지고 있는 구조라고 할 때,
객체를 테이블에 맞추어 모델링하게 되면
Member안에 Long 타입으로 teamId 필드를 줘야 한다. 그래야 객체를 저장할 때 편하다.
하지만 객체다운 모델링을 하려면
Member안에 Team타입의 team을 필드를 줘서 참조로 연관관계를 맺어야 한다.
하지만 이렇게 모델링을 하면 DB에 저장할 때 까다롭다! 그래도 member.getTeam().getId()로 저장할 수는 있음.
조회할 때도 까다롭다. Member와 Team을 Team_ID가 같은 조건에서 Join하여 조회해야 한다.
객체 그래프 탐색
객체는 자유롭게 객체 그래프를 탐색할 수 있어야 한다.
그런데 SQL로 데이터를 가져오게 되면 처음 실행하는 SQL에 따라 처음 탐색 범위가 결정된다.
예를 들어 Team과 Member을 Join했다면, member에서 Team은 가져올 수 있지만, Order은 가져올 수 없다.
>> Entity의 신뢰성이 깨진다. 내가 Member에서 연결되어 있는 객체의 어디까지 조회할 수 있는가?를 직접 찾아보아야 한다.
그렇다고 모든 객체를 미리 로딩할 수는 없으니 상황에 따라 어디까지 조회할 것인지 정하여 메서드를 여러 개 생성해줘야 한다.
비교하기
같은 memberId로 Member1와 Member2를 불러왔다면 Member1과 Member2의 객체는 다른 객체이다. 쿼리 문을 써서 새로운 객체를 만들었기 때문.
객체답게 모델링 할수록 매핑 작업이 늘어난다..!
객체를 자바 컬렉션에 저장하듯이 DB에 저장할 수는 없을까?
JPA - Java Persistence API가 나오게 된 배경.
'STUDY > JPA' 카테고리의 다른 글
[3-3] 플러시 (0) | 2023.07.05 |
---|---|
[3-2] 영속성 컨텍스트의 이점 (+Batch) (0) | 2023.07.04 |
[3-1] 영속성 컨텍스트란? (0) | 2023.07.03 |
[2-1] JPA 시작하기 (0) | 2023.06.30 |
[1-2] JPA 소개 (0) | 2023.06.29 |