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

 

객체와 관계형 데이터베이스의 차이는 크게 4가지 정도 정리할 수 있다.

1. 상속, 2. 연관관계 3. 객체 그래프 탐색, 4. 비교하기

 

1. 상속

관계형 DB에서 객체의 상속 관계와 그나마 비슷한 것은 Table의 슈퍼타입 서브타입 논리모델이다.

Problem] 객체를 분해해서 저장하기 때문에 슈퍼타입 테이블과 서브타입 테이블 JOIN 결과에 값을 채워넣고 반환 후 조회하는 과정을 거쳐야 한다.

 

자바 컬렉션에 저장한다면? -> list.add(객체)

                  조회한다면? -> list.get(객체)

객체는 부모타입으로 조회 후 다형성을 활용하여 사용할 수도 있다.

//Kotlin

val item1: Child = list.get(childId)

val item2: Parent = list.get(childId)

 

-> 관계형 DB쓰는 순간 SQL 작업을 직접 다 해줘야한다.

 

2. 연관관계

이런 연관관계가 있다고 하자.

멤버는 어떤 팀에 소속되어 있습니다.

객체는 참조 사용 : member.team

테이블은 외래키 사용 : JOIN ON MEMBER.TEAM_ID = TEAM.TEAM_ID

 

객체에서는 team만으로 member를 접근할 수 없으나,
테이블은 team 만으로 member를 JOIN해서 조회 가능하다 (양방향)

 

이렇게 객체와 테이블은 연관관계의 표현이 다르다.

보통은 객체를 테이블에 맞춰 모델링한다.

Problem] 객체다운 모델링 힘듦.

 

객체 모델링 조회 시 새 객체 만들고 DB에서 조회한 정보를 모두 입력, 그 후 연관관계 설정해 주어야 한다.

Problem] 번거로움

 

3. 객체 그래프 탐색

 : 객체는 자유롭게 객체 그래프 탐색할 수 있어야한다.

객체 그래프

Problem1] 처음 실행하는 SQL 따라 탐색 범위가 결정됨.

SELECT M.*, T.8
	FROM MEMBER M
    JOIN TEAM T ON M.TEAM_ID = T.TEAM_ID

라는 쿼리를 날렸을 때 

//Kotlin
member.team	//OK
member.order	//null

team 은 조회되지만 order는 조회되지 않는다.

 

Problem2] 엔티티 신뢰 문제

Layered Architecture의 경우 다음 계층에서 그 위의 Layer를 신뢰해야 한다.
그렇지 않으면 엔티티의 신뢰 문제가 발생한다.

위 그림을 보면 Member 객체가 있고 그것의 프로퍼티로 Team 객체와 Order객체가 있다.

Problem1처럼 쿼리를 날리고 

//Kotlin
val order = member.order

위 코드를 실행하면 order은 null값을 가진다.

객체지향적인 개발을 할 때에는 order이 member의 프로퍼티인 Order객체라고 신뢰하고 다음 단계로 넘어가야 하는데 이런 경우 반환된 객체의 멤버를 자유롭게 호출할 수 없게 된다.

 

 -> Problem3] 그렇다고 모든 객체를 미리 로딩할 수는 없다.

    -> Sol) 상황에 따라 동일한 회원 조회 메서드 여러개 생성

//Kotlin

//Member
memberDAO.getMember()

//Member, Team
memberDAO.getMemberWithTeam()

//member, team, delivery
memberDAO.getMemberWithTeamWithDelivery()

 

결론 : SQL직접 다루게 되면 진정한 의미의 계층 분할이 어렵다.

4. 비교하기

같은 Id로 객체를 조회해도 조회 코드에서 새 객체 생성 후 반환하기 때문에 서로 다른 객체라고 나온다.

(자바 컬렉션에서 조회 시 참조 값이 같기 때문에 같은 객체라고 나온다.)

 

---

 

객체답게 모델링 할 수록 매핑 작업만 늘어나고 힘들어진다.

Solution은?

JPA!

 

 

[출처]
자바 ORM 표준 JPA 프로그래밍 - 기본편
https://www.inflearn.com/course/ORM-JPA-Basic/dashboard