SQL Mapper vs ORM

📌 SQL 중심적인 개발의 문제점

 

1. 반복적인 SQL 작성
2. DBMS에 종속적
3. 객체와 관계형 DB의 패러다임 불일치

 

📌 객체 vs 관계형 DB <패러다임 불일치>

 

🔎 상속

 

상속 관계 [객체 vs 관계형 DB]

 

관계형 DB는 위와 같은 상속 관계에 있을 때 데이터 저장과 조회가 다음과 같다.

 

//저장
INSERT INTO ITEM ...
INSERT INTO ALBUM ...

 

# 조회
- 각각의 테이블에 따른 조인 SQL
- 상속 관계이므로 부모 객체를 통해 조회
- 각각의 객체 생성
...

 

이처럼 저장과 조회 때마다 부모와 자식은 한 몸처럼 따라다니기 때문에 관계형 DB에서는 상속 관계를 사용하지 않는다.

 

반면, 자바에서는 컬렉션 객체를 사용하여 다형성을 활용하면 부모 타입으로 쉽게 조회 가능하다.

 

list.add(album); //저장
Item item = list.get(albumId); //조회

 

🔎 연관 관계

 

연관 관계&nbsp;[객체 vs 관계형 DB]

 

• 객체는 참조 값을 통해 연관 관계 객체에 접근 ➡ member.getTeam()
• 테이블은 외래키를 사용하여 연관 관계 객체에 접근 ➡ FROM A a JOIN B b ON A.id = B.id

 

✔ 설계

 

 

테이블에 맞춰 객체를 저장하면 다음과 같다.

 

도메인에 외래키 저장

 

반면, 객체에 맞춰 회원을 설계하면 연관 관계 객체의 참조 값을 갖게 된다. 이때 INSERT문은 FK를 필요로 하기 때문에 참조 객체에서 이것을 뽑아내는 로직이 추가되어야 한다.

 

도메인에 참조값 저장

 

✔ 로직

 

로직에서도 차이를 보인다.

 

관계형 DB는 연관 관계 테이블을 조회하기 위해 쿼리와 객체 바인드가 함께 따라다닌다. 원인은 자바처럼 컬렉션으로 관리되지 않기 때문에 조회, 저장, 연결 모두 따로 놀기 때문이다. 즉, 컬렉션이라는 관리자가 없다.

 

• 조회 ➡ SQL
• 저장 ➡ 객체 생성 및 바인드
• 연결 ➡ 프로퍼티 함수

 

 

 

하지만 자바는 컬렉션을 통해 관계가 있는 두 객체를 편리하게 다룰 수 있다.

 

list.add(member);

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

 

🔎 객체 그래프 탐색

 

객체 그래프 탐색 [객체 vs 관계형 DB]

 

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

 

그런데, 관계형 DB는 처음 실행하는 테이블에 따라 탐색 범위가 결정된다. 즉, 조인 가능한 엔티티가 아니면 한 번의 SQL로 접근할 수 없다.

 

그래서 진정한 의미의 계층 분할이 어렵다. 물리적으로는 분리되었으나 논리적인 분할에 실패한 것이다. 그 이유는 일부 객체를 탐색하기 위해 필요한 모든 테이블을 로딩해야 하는 상황이 발생하기 때문이다.

 

🔎 비교하기

 

DAO를 통해 동일 ID로 조회한 두 객체는 서로 다르다.

 

String memberId = "100";
Member member1 = memberDAO.getMember(memberId);
Member member2 = memberDAO.getMember(memberId);
//member1 != member2

 

하지만 컬렉션을 통해 동일 ID로 조회한 두 객체는 서로 같다.

 

String memberId = "100";
Member member1 = list.get(memberId);
Member member2 = list.get(memberId);
//member1 == member2

 

이러한 객체와 관계형 DB의 차이를 극복하기 위한 기술로 SQL Mapper 및 ORM이 등장했다.

 

📌 SQL Mapper vs ORM <개요>

 

🔎 SQL Mapper란

 

객체와 테이블의 필드를 매핑하여 데이터를 객체화하는 기술

 

객체와 테이블 간의 관계를 매핑하는 것이 아닌, SQL문을 실행해 쿼리 수행 결과를 어떤 객체에 매핑할지 바인딩하는 방법이다. 따라서 DBMS에 종속적인 방법이다.

 

🔎 ORM(Object-relational Mapping)이란

 

객체와 데이터베이스 테이블을 매핑하여 데이터를 객체화하는 기술

 

CRUD 관련 메소드를 사용하면 자동으로 SQL이 만들어져 개발자가 반복적인 SQL을 직접 작성하지 않아도 되고, DBMS에 종속적이지 않다. 또한, 복잡한 쿼리의 경우 JPQL을 사용하거나 SQL Mapper를 혼용하여 사용할 수 있다.

 

 

Reference:

https://deveun.tistory.com/entry/SQL-Mapper%EC%99%80-ORM-%EC%B0%A8%EC%9D%B4

SQL Mapper와 ORM 차이

 

📌 SQL Mapper vs ORM <로직>

 

서비스 계층과 웹 계층을 생략하고 데이터 접근 계층만 작성하여 비교했다.

 

🔎 SQL Mapper - Mybatis

 

#쿼리를 작성하는 xml 파일
<mapper namespace="a.b.c">
    <select id="test" ...>
        //SQL 쿼리
    </select>
</mapper>

 

@Repository
public class DaoImpl implements DaoInterface {
    private static final String namespace = "a.b.c";
    
    @Inject
    private Sqlsession sqlSession; //SQL 명령 실행기
    
    @Override
    public List<Member> selectList() throws Exception {
    	sqlSession.selectList(namespace + ".test"); //SQL을 작성한 파일과 연결 후 조회
    }
}

 

Reference:

https://ninedc.tistory.com/entry/Spring%EC%8A%A4%ED%94%84%EB%A7%81-mybatis%EB%A7%88%EC%9D%B4%EB%B0%94%ED%8B%B0%EC%8A%A4-mysql-%EC%98%88%EC%A0%9C%EB%A1%9C-%EB%94%B0%EB%9D%BC%ED%95%98%EA%B8%B0

Spring(스프링) & mybatis(마이바티스) & mysql 예제로 따라하기

 

🔎 ORM - JPA

 

@Repository
@RequiredArgsConstructor
public class MemberRepository {
    
    private final EntityManager em; //JPA의 EntityManager == DB Connection
    
    public Member findOne(Long id) {
        return em.find(Member.class, id); //조회
    }
    
}

 

🔎 정리

 

MyBatis와 JPA는 크게 2가지 차이점을 볼 수 있다.

 

1. JPA는 쿼리를 작성하는 부분이 없다.
2. MyBatis의 쿼리는 특정 DBMS를 따른다.

 

결론적으로 JPA는 쿼리를 자동화했고, DBMS에 종속적이지 않다는 것이다.

 

Reference:

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

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