[JPA] SQL을 직접 다룰 때 발생하는 문제점

1-1. SQL을 직접 다룰 때 발생하는 문제점

https://www.inflearn.com/course/ORM-JPA-Basic/dashboard

자바 ORM 표준 JPA 프로그래밍 - 기본편 - 인프런 | 강의

http://www.kyobobook.co.kr/product/detailViewKor.laf?mallGb=KOR&ejkGb=KOR&barcode=9788960777330 

자바 ORM 표준 JPA 프로그래밍 - 교보문고

정리

• 객체 모델과 관계형 데이터베이스 모델은 지향하는 패러다임이 서로 다르다. 
• 이러한 패러다임의 차이를 극복하고자 개발자가 많은 시간과 코드를 소비하게 된다.
• 정교한 객체 모델링을 할 수록 패러다임의 불일치가 커진다. 물론 개발자가 소비하는 시간도 커진다.
• JPA를 통해 패러다임의 불일치 문제를 해결하고, 정교한 객체 모델링을 유지한다.

---

1. 반복된 코드작업

보통 하나의 테이블이 완성되면 CRUD 의 기능을 위해 Java 단에서도 추가적인 개발이 필요하다.

아래는 그 개발의 프로세스이다.

 

SELECT

1) 조회용 SQL을 작성한다.

2) JDBC API 를 이용해서 SQL을 실행한다.

3) 조회 결과를 DTO, VO등에 매핑한다.

 

INSERT

1) 데이터 삽입용 SQL을 작성한다.

2) 객체에서 값을 꺼내 SQL에 매핑한다.

3) JDBC API 를 이용해서 SQL을 실행한다.

 

이후 업데이트, 삭제, 등의 작업을 위해서는 DAO, SQL문, 테이블이 변경된다면 VO까지 다양한 코드의 수정이 필요한다.

테이블에 필드가 추가된다면 각각의 코드를 업데이트 해야한다.

 

=> SQL에 의존적인 개발을 피하기 어렵다.

 

2. 패러다임의 불일치

객체지향 프로그래밍은 추상화, 캡슐화, 정보은닉, 상속, 다형성 등의 시스템의 복잡성을 제어할 수 있는 다양한 장치들을 제어한다.

 

• 객체를 영구 보환하는 저장소 : RDB, NoSQL, File -...

=>현실적 대한은 관계형 데이터베이스 (검색 등의 서비스를 위해)

 

객체 => SQL 변환 => RDB

(Sql Mapper의 일을 하고 있다.)

 

 

2-2. 객체와 관계형 데이터 베이스의 차이

객체와 데이터베이스와 구분되는 특징으로는 

1. 상속

• 객체의 상속 관계 vs Table의 슈퍼타입 서브타입의 관계
• 객체를 분해해서 저장해야 한다. item과 detail을 Join작업한다
• 자바 컬렉션에 저장한다면? (list.add(obj))
• JPA : 개발자는 자바 컬렉션에서 객체를 저장하듯이 JPA 객체를 저장하면 된다.

 

2. 연관관계

• 객체는 참조를 사용해서 다른 객체와 연관관계를 가진다. 참조에 접근해서 연관된 객체를 조회한다. 
• 테이블은 외래 키를 이용해서 다른 테이블과 연관관계를 가지고 조인을 사용해 연관된 테이블을 조회한다.

 

• 객체는 참조된 객체를 찾아갈수 있으나, 참조된 객체는 상위객체를 찾아갈 수 없다.
• 테이블은 ID를 이용해 상/하위 객체를 찾아갈 수 있다.
• 객체를 테이블에 맞춰서 모델링해야한다 (Team 이 아닌 Long teamId)
• 객체와 하위객체는 Join해서 SQL로 가져오고, 하위객체를 생성한 후 상위객체를 생성하고 set하여 객체를 조회한다.
•  
• Entitiy의 신뢰도 문제 : 모든 객체를 미리 로딩할 수 없다. 처음 SQL을 실행한 후 안쪽의 엔티티를 쓰고자 해도 이것의 값이 있는지 확인 불가능
• 계층형 아키텍쳐지만 게층 분할이 되지 않는다.
•  
• 자바 컬렉션을 이용했을때와 SQL을 이용했을때 참조값이 달라서 미스매치가 이루어진다.

• 식별자가 같고, 결과는 같지만 객체는 다르다.

=> 객체답게 모델링 할수록 매핑작업이 늘어난다.

객체를 자바 컬렉션에 저장하듯이 DB에 저장하는 것 = JPA

 

3. 데이터타입

4. 데이터 식별 방법