2. 객체지향과 관계형DB

우리는 객체지향 언어를 이용해

객체를 관계형 DB에 저장한다.

 

근데, 관계형 DB에 저장하려면 SQL을 작성해야 한다.

 

이것이 SQL 중심적 개발의 문제점

 

객체 <-> 관계형 DB

에서 개발자가 SQL문을 작성하며 Mapper 역할을 해줘야 함.

 

기능마다, 다루는 데이터마다 SQL문을 다 작성 해줘야 함..

 

또 SQL문 이렇게 다 작성했는데 갑자기 데이터 하나를 더 추가시켜달라고 하면..

 

 

대부분 관계형 DB를 써야 하기에, 객체와 관계형 DB 사이의 패러다임 불일치가 발생한다.

 

1. 상속

2. 연관 관계

3. 데이터 타입

4. 데이터 식별 방법

 

1. 상속

DB에는 상속 관계 라는 것이 없다.

가장 비슷한 것은 슈퍼타입, 서브 타입의 관계. 기법중의 하나임.

부모같은 테이블을 만들고, 자식같은 테이블을 만듦.

필요한 것은 join해서 가져옴.

위 보면 저렇게 자식들이 부모의 PK를 열로 가지고 있다가 필요 시에 join해서 가져옴.

 

그럼 만약 Album을 저장하고 싶다고 한다면..

insert into item..

insert into album(item_id .......) values(itemId, .....)

 

insert는 사실 뭐 저정도면 할만한데, 

조회할 때 item과 album을 같이 join해서 가져와야 함..

 

그래서 이렇게 복잡하기 때문에,

DB에 저장될 객체는 상속관계를 쓰지 않는다.

 

또 이거를, Album 뿐만 아니라 Movie, Book 까지 따로 만들어야 함. (아니면 조건으로 추가하던지.)

 

 

 

2. 연관 관계

객체는 참조를 사용한다. 예 : member.getTeam();

 

DB는 외래 키를 사용하여 JOIN한다. 예 : join on member.team_id = team.team_id

member가 team의 pk에 대한 정보를 가지고 있다고 생각하면 된다. 바깥에 대한 키니 외래키, 포링키 라고도 함.

줄여서 FK라고 하는데, 이것도 이 연관관계에 대한 정보를 PK선언하듯이 테이블 만들 때 할 수 있음.

 

primary key (id) 이렇게 pk 선언 했듯,

 

foreign key (category_id) references category(id)

foreign key (나의열) references 외부테이블 (외부테이블열)

 

join하면 나의 열의 값으로 외부테이블의 열과 맞춰 그 값을 가져올 수 있음. 

 

 

 

그러면 도메인 객체 형식도,

이런 식으로 만들어야 함.

 

객체다운 모델링은 아님. 객체는 참조로 가져와야 함.

 

아니면

내 눈엔 이게 훨씬 낫긴 함.

 

뭐 조회할 때도 먼저 member 가져온 다음에 team_id 뽑아서 team에서 조회하면 되지 않나?

 

그럼 생성자를 id, username만 넣을 수 있는 생성자 만들어 줘야 겠고,

위 처럼 team 만들어서 team 넣어주고.

 

 

저렇게 join으로 일단 둘다 가져오고,

둘다 만들어서 따로따로 set 한 다음에,

마지막으로 member에 team을 넣어주면 ..

 

뭐 번거롭다고 하긴 하지만 못할건 아닌데..

 

근데 더 큰 문제가,

처음 실행하는 SQL문에 따라서 객체에서 탐색할 수 있는 범위가 결정된다.

예를 들어 Member가 team도 있고, order도 있고, delivery도 있다고 하면,

 

이걸 모두 Join 시켜서 가져올 건가?

 

그러면, 매번 order나 team이 필요한 것도 아닌데,

sql에 많은 조건을 줘 상당한 성능 낭비가 된다.

이걸 쿼리로 만들어 본다고 생각해 보셈.

뭐 이것도 못할 건 아님.

먼저 member에서 team키, order키 가져오고 

order에서 delivery 키, orderItem키 가져오고,

orderItem에서 item키 가져와서 item 가져오고 또 item에서 category 키 가져와서 category 테이블에서 조회해서 가지고 오고..

근데 보통은 성능을 위해 sql 날리는 것은 최대한 한번에 하려고 함.

여튼..

 

 

그렇다고 또 모두 가져오지 않으면,

내가 참조하는 객체에 대한 신뢰가 떨어지게 된다.

이게 팀을 지금 가지고 있는건지.. 

 

알려면 일일이 sql 쿼리문을 날렸던 그 곳으로 가서 살펴보아야 한다.

 

그러면, 상황에 따라 일부만 조회하는 메소드를 만든다면.. 좋은 방법으로 보이긴 한다.

팀까지는 괜찮았는데, 그 뒤부터는 너무 가시성이 떨어진다.

 

객체가 3개라 그렇지, 더 있다고 생각해보면..

 

 

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

 

 

그래서,

객체를 자바 컬렉션에 저장 하듯이 DB에 저장할 수는 없을까?

해서 나온 게 

Java Persistence API