김영한 강사님의 해당 강의를 통해 해당 글을 작성하였습니다.
1. SQL 중심적인 개발의 문제점
지금 시대는 '객체'를 '관계형 DB'에 관리한다.
지나치게 많고 반복적인 SQL 코드는 개발자에게 하나의 시련이였다.
왜일까?
자바 객체를 SQL로 , SQL을 자바 객체로 어떻게 바꾸어야 할까? 🤔
Q. 만약 중간에 필드를 추가해야 할 경우
그 때마다 우리는 SQL을 수정해주어야 할 것이다.
만약 그 쿼리가 길고 무수하다면 일일히 수정하는 일은 비효율적일 것이다...
관계형 DB는 데이터를 잘 정규화해서 보관하는 것이 목표
객체는 속성과 기능이 잘 묶여서 캡슐화하는 것이 목표
이 둘의 패러다임이 안 맞는데 객체를 관계형 DB에 넣으려고 하니까 문제가 되는 것이다
객체를 영구 보관하는 장소들
생각해보자 우리 객체를 영구 보관하는 곳에는 다양한 저장소가 있다.
RDB(관계형 DB), NoSQL , File, OODB(지금은 잘 안 쓴다)
관계형 DB에 넣는 것이 제일 좋다.
(현실적으로 File에 넣으면 검색이 x)
객체 vs RDB의 차이
Q. 상속
객체 (ㅇ), RDB(ㅇ 객체랑은 유사하지 x)
Q. 연관관계 *
객체: 참조 , RDB: PK-FK로 조인해서 찾아냄
- 데이터 타입
- 데이터 식별 방법
예를 들어보자
이의 경우 Album에서
저장의 경우
- 객체를 분해
- 각각의 테이블이 다르기 때문에 INSERT 문을 넣어주면 된다.
INSERT INTO ITEM ...
INSERT INTO ALBUM …
조회의 경우
- 각각의 테이블에 따른 조인 SQL 작성...
- 각각의 객체 생성...
- 상상만 해도 복잡
중간 매핑과정이 너무 복잡한 것이 문제가 된다.
자바 컬렉션에서 쓴다면..?
- 저장시, list.add(album);
- 조회시,
좀 더 문제가 단순해진다. 직접 가져와서 일일히 매핑해줄 때와 다르게
연관관계
- 객체는 참조를 사용:
* member.getTeam() - 테이블은 외래 키를 사용:
* JOIN ON M.TEAM_ID = T.TEAM_ID
테이블은 PK,FK 덕에 조인을 이용해서 양방향으로 접근이 가능한데, 객체는 단방향 밖에 접근이 안됨.
그래서 객체를 테이블에 맞추어 모델링 해보았다.
여기서 드는 생각은 DB의 외래키는... 객체지향적으로 보면 '참조'로 연관관계를 맺어야 한다는 생각이 든다.
이번엔 좀 더 객체지향적으로 객체를 '참조'하여 '연관관계'를 맺었다.
[저장의 경우]
외래키 값 대신 참조가 있네? 그렇다면 값(외래키 값=> teamId)을 뽑아오면 된다.
[조회의 경우]
참 길고 복잡해진다..
그러다 보니 오히려 자바 컬렉션에 관리하는 식이 객체지향적으로 좋다.
코드 한 줄로 되니까 너무 편하다.. 근데 DB에 넣게 되면 이런 것들이 전부 헝클어지니 문제가 된다...
처.음. 실행하는 SQL에 따라 탐색 범위가 결정
곧 엔티티의 신뢰 문제가 발생한다.
왜냐하면 이전에 select 가 어떤 쿼리가 날라갔고 왔는지를 일일히 확인할 수 없어서
이 코드를 직접 눈으로 보지 않는 이상 신뢰가 없다...
물리적으로 나뉘어져 있지만 논리적으로는 연관이 있어서...
그렇다고 일일히 미리 로딩할 수는 없다. (모든 객체들을? 🤪)
결국 이 대안으로 상황에 따라 여러벌의 메서드를 생성해주는 식이 있다...😥
자바 컬렉션에서 다룰 때와 SQL에서 다룰 때 상황에 따라 복잡해진다..
결과적으로 코드가 번잡해진다..
1. SQL문에서
왜 다를까?
SQL문으로 일일히 생성해서 new로 반환을 해주다 보면 참조하는 곳이 달라진다.
2. 자바 컬렉션에서
레퍼런스 곧 참조 값이 같으니까 둘이 같다.
정리
- 객체 답게 모델링 할 수록 매핑 작업만 늘어난다
자바 컬렉션에 저장 하듯이 DB에 저장할 수는 없을까?
해답은 JPA!
JPA의 소개
JPA와 ORM이란?
[JPA는...]
- 자바 진영의 ORM 기술 표준
[ORM은?]
- Object-relational mapping(객체 관계 매핑)
- 객체는 객체대로 설계
- 관계형 데이터베이스는 관계형 데이터베이스대로 설계
- ORM 프레임워크가 중간에서 매핑
- 대중적인 언어에는 대부분 ORM 기술이 존재
어디에서 동작하는가?
- 애플리케이션에서 JPA에게 명령을 내리고 JPA는 JDBC API에게 명령을 내려 DB에 SQL을 보내고 결과를 반환 받아오는 식이다.
저장, 조회
- 객체를 던져주면 JPA가 이 객체를 분석해준다.
- PK를 던져주면 SQL을 JPA가 생성하여 결과를 반환 받으면 그 결과를 가지고 객체에 다 매핑을 해준다.
JPA를 왜 사용해야 할까?
- SQL 중심적인 개발에서 객체 중심으로 개발
- 생산성
- 유지보수
- 패러다임의 불일치 해결
- 성능
- 데이터 접근 추상화와 벤더 독립성
- 표준
1. 생산성
• 저장: jpa.persist(member)
• 조회: Member member = jpa.find(memberId)
• 수정: member.setName(“변경할 이름”)
• 삭제: jpa.remove(member)
되게 명령어가 단순해졌고 편리해졌다.
2. 유지보수
이전에는 필드 변경시 일일히 모든 SQL을 다 수정해줬어야 했는데...
그냥 필드만 추가해주면 된다.
나머지 SQL은 JPA가 알아서 생성해줄 것이기 때문이다.
JPA와 패러다임의 불일치 해결
1.JPA와 상속
[저장]
[조회]
2.JPA와 연관관계와 객체 그래프 탐색
3. JPA와 비교하기
4. JPA의 성능 최적화 기능
4-1. 1차 캐시와 동일성 보장
- 같은 트랜잭션 안에서는 같은 엔티티를 반환 - 약간의 조회 성능 향상
- DB Isolation Level이 Read Commit이어도 애플리케이션에서 Repeatable Read 보장
같은 트랜잭션 내에서 이전에 같은 엔티티를 다시 한 번 조회한다면 SQL문을 다시 쓰는게 아니라 캐시를 이용해서 반환한다. => SQL 1번만 씀
4-2. 트랜잭션을 지원하는 쓰기지연(INSERT)
- 트랜잭션을 커밋할 때까지 SQL을 모음 (INSERT)
- JDBC BATCH SQL 기능을 사용해 한번에 모아서 SQL 전송
4-2. 트랜잭션을 지원하는 쓰기지연(UPDATE)
4-3. 지연 로딩과 즉시 로딩
• 지연 로딩: 객체가 실제 사용될 때 로딩
• 즉시 로딩: JOIN SQL로 한번에 연관된 객체까지 미리 조회
즉시로딩의 경우 가져올 때 매번 같이 가져온다면 차라리 한 번에 미리 조회할 때 쓰인다.
