JPA) SQL 중심적인 개발의 문제점

1. 데이터베이스 세계의 헤게모니(주도권) : 관계형 DB

요즘엔 개발할 때 대부분 객체지향 언어를 사용함

데이터를 저장하기 위해 RDB도 사용함

 다양한 유형의 데이터베이스의 주도권은 RDB(Oracle, MySQL, ...)

그래서 지금 시대는 객체를 관계형 DB에 저장해서 관리해야하는 시대임

하지만 문제는 코드를 보면 다 DB SQL임!

결국 SQL 중심적인 개발이 된다

테이블 당 모든 CRUD 쿼리 다 짜야 함

 

갑자기 tel 필드를 추가해달라고 하면? -> 미리 짜놓은 SQL에 tel 컬럼을 추가해야 함 : 너무 번거로움

SQL에 의존적인 개발을 피하기 어려움

 

 

 

2. 패러다임(체계, 틀)의 불일치. 객체 VS 관계형 데이터베이스

객체지향 사상과 관계형 데이터베이스 사상은 다름

RDB는 데이터를 정규화해서 보관하는 것이 목표고

객체지향은 필드나 메소드를 캡슐화해서 사용하는 것이 목표

객체를 관계형 DB에 넣으려고 하니 여러가지 문제가 발생함

 

객체 중심으로 생각할 때

객체 저장 시 다양한 곳에 저장할 수 있음

하지만 현실적인 대안은 RDB이다

File은 검색이 너무 어려움(하나하나 다 열어보거나 Object로 변환해야 검색 가능함)

NoSQL은 주로 쓰는 DB가 아님

OODB는 거의 안 씀

 

 

객체를 SQL로 바꿔야 저장을 할 수 있는데 결국 SQL을 짜야 한다

결국 개발자는 SQL을 짜야 한다

 

 

객체와 관계형 데이터베이스의 차이
1. 상속
2. 연관관계
3. 데이터 타입
4. 데이터 식별 방법

1. 상속 : RDB에는 없음(유사한 건 있긴 함)

2. 연관관계 : 객체는 참조를 가지고 연관관계를 가지지만, DB는 PK/FK로 관계를 찾을 수 있음

 

 

1. 상속

RDB에는 상속과 그나마 유사한 기술이 슈퍼타입/서브타입 관계가 있음

객체의 연관관계를 생각해서 DB 설계를 했다고 치자

 

Album 저장 시
1. 객체 분해
2. INSERT INTO ITEM ...
3. INSERT INTO ALBUM ...

Item insert 쿼리, Album insert 쿼리 각각 다 짜줘야 함

 

Album 조회 시
1. 각각의 테이블에 따른 조인 SQL 작성
2. 각각의 객체 생성...
3. 상상만해도 복잡.....
4. ...
5. 그래서 DB에 저장할 객체에는 상속 관계를 안 쓴다

 

DB가 아닌 자바 컬렉션에 저장한다면?
list. add(album); 
그냥 꺼내오면 됨

 

DB가 아닌 자바 컬렉션에 조회한다면?
Album album = list.get(albumId);

부모 타입으로 조회 후 다형성 활용
Item item = list.get(albumId);

 

객체 세상에서 돌기 때문에 다형성을 활용할 수 있음

DB가 사용되는 순간 복잡해지는것임..!!

 

 

하지만, 문제점이 있음

객체는 Member에서 Team으로 갈 수 있지만

Team에서 Member로 갈 수 없음

하지만 RDB에서 PK/FK를 사용한다면

Member에서 Team으로, Team에서 Member로 조회 가능함

 

 

객체 주소를 DB에 넣을 수 없으니 객체에서 ID값을 뽑아와 DB에 저장

 

객체지향적으로 테이블을 설계했을 때 문제는 조회 시 발생함!

조인해서 Member랑 Team을 모두 한꺼번해 조회해오면

이것을 Member와 Team 데이터를 분리해서 세팅해줘야 함

Member와 Team 관계를 설정해주고 그 결과를 리턴해줘야 함

번거롭다

그래서 큰 DTO 클래스를 만들어 데이터를 다 떄려박음

 

 

RDB가 아닌 자바 컬렉션에 데이터를 넣는다 한다면?

객체 모델링, 자바 컬렉션에 관리
list.add(member);

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

간단하게 해결된다

 

RDB 사용 시 생산성이 떨어진다

 

---

이런 연관관계가 있다 해도 마음껏 호출할 수 있는가? 아니다

처음 실행하는 SQL에 따라 탐색 범위가 결정되기 때문이다

처음 실행하는 SQL에 따라 탐색 범위 결정
SELECT  M.*, T.*
FROM   MEMBER M
JOIN     TEAM T ON M.TEAM_ID = T.TEAM_ID;

member.getTeam();     //가능
member.getOrder();    //null

이것이 결국 엔티티 신뢰 문제를 일으키게 됨

 

이 코드는 다른 사람이 짠 코드라고 치자

find 함수가 어떤 것을 호출하고 어떤 쿼리가 실행되었는 지 직접 보지 않는 한

신뢰할 수가 없음!

 

그렇다고 모든 객체를 미리 로딩할 수는 없음

대체하는 방법은

상황에 따라 동일한 조회 메소드를 여러 번 생성하는 것

SQL을 다루게 된다면

계층형 아키텍쳐에서 진정한 의미의 계층 분할이 어렵다

 

member1 과 member2를 == 로 비교한다면 주소값을 비교하는 것이기 때문에 false가 나옴

 

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

 

 

객체답게 모델링 할 수록 매핑 작업만 늘어난다

 

객체를 자바 컬렉션에 저장하듯기 DB에 저장할 수는 없을까?? -> 해답은 JPA