[ Node.js 숙련주차1 (1-0)] ORM과 Prisma

 

▸ ORM이란?

객체 관계 매핑(Object-relational mapping; ORM)은 데이터베이스와 객체 지향 프로그래밍 언어 간의 호환되지 않는 데이터를 변환하는 프로그래밍 기법이다. 객체 지향 언어에서 사용할 수 있는 "가상" 객체 데이터베이스를 구축하는 방법이다. 객체 관계 매핑을 가능하게 하는 상용 또는 무료 소프트웨어 패키지들이 있고, 경우에 따라서는 독자적으로 개발하기도 한다.

참조URL : 객체 관계 매핑 - 위키백과, 우리 모두의 백과사전 (wikipedia.org)

객체 관계 매핑 - 위키백과, 우리 모두의 백과사전

( * Node.js 환경에서는 TypeORM, Prisma, Sequelize 등 다양한 ORM이 존재한다. 나는 Javascript 환경뿐만 아니라 TypeScript에서도 사용할 수 있고, ORM 개념을 학습하기 쉬운 Prisma를 바탕으로 프로젝트를 진행했다. 때문에 Prisma 기준으로 ORM에대한 내용을 서술했다. ) 

 

---

 

▸ Prisma란? 

Prisma는 ORM(Object Relational Mapping)으로써 Javascript 객체(Object)와 데이터베이스의 관계(Relation)을 연결(Mapping) 해주는 도구이다.

 - Prisma와 같은 ORM은 여러가지의 관계형 데이터베이스(RDB)를 사용할 수 있다. MySQL, Oracle, MariaDB, PostgreSQL와 같은 다양한 데이터베이스를 사용할 수 있다.

 

---

 

▸ ODM (Object Document Mapping)과 어떤차이일까? 

- Prisma와 mongoose를 비교하면 그 차이를 쉽게 알 수 있다.

mongoose의 경우 ODM(Object Document Mapping)으로 Javascript의 객체를 Document(문서)와 연결하지만,

Prisma는 ORM(Object Relational Mapping)으로 Javascript의 객체와 데이터베이스의 관계(Relation)를 연결해주는 차이점이 있다.

 

mongoose는 지원하는 데이터베이스는 MongoDB 밖에 존재하지 않는다.  Prisma의 경우 RDBMS에 해당하는 다양한 데이터베이스를 사용할 수 있다는 장점있다. (* Prisma의 경우 MongoDB를 지원한다. )

mongoose의 경우 Schema의 형태로 컬렉션(Collection)에 대한 속성을 설정하였다면, Prisma의 경우 Model의 형태로 테이블(Table)의 속성을 설정할 수 있다. (* MongoDB의 컬렉션(Collection)과 MySQL의 테이블(Table)은 동일성을 가지고있다.

 

 

▸ ORM의 장점과 단점이 뭘까? 

 

과거에는 MySQL을 사용하려 할때, ORM을 사용하지 않고, 모든 코드를 SQL을 사용하는 Raw Query 형태로 구현하여 사용하였다.

하지만 Prisma와 같은 ORM이 생기게 되면서 위와 같은 상황들이 많이 줄어들게 되었다.

그러면 프로젝트를 구현할 때, Raw Query로 구현하지 않고, ORM을 사용하는 이유가 무엇일까?

 

Prisma와 같은 ORM을 사용하는 가장 큰 이유는 대표적으로 2가지가 있다.

 

1) 프로덕션에서 사용하는 데이터베이스가 언제바뀔 지 알 수 없다.처음은 가장 보편적으로 사용하는 MySQL을 사용하고 있었다. 그러나 시간이 지날수록 개발자들의 유지보수 만으로 DB를 관리하기 어려워져 기술지원이 활발한 Oracle로 DB를 변경하려할 때 ORM을 사용하지 않는 개발자들은 두가지의 선택의 기로에 서게된다.

 

1. 서비스 중인 프로덕션의 모든 Raw Query코드를 MySQL에서 Oracle로 변경하는 것을 고려하거나,

2. Oracle로 변경하지 않고, 어려운 현재 상황을 감내하고 계속 MySQL을 쓴다

 

하지만, ORM을 도입하였을 경우 여러분들은 이런 상황을 겪지 않고, 단순히 ORM의 속성값만 변경할 경우 언제든지 자유롭게 DB를 변경할 수 있게 되어 개발할 때 선택의 폭이 넓어지게 된다.

 

2) 데이터베이스에서 사용하는 DB 또는 Table 속성이 변경되었을 때 빠르게 수정이 가능하다.

 

DB를 사용하는 코드를 모두 Javascript에서 Raw Query로 구현하였다고 가정해보자.

프로덕션에서 서비스를 진행 중 갑작스럽게 클라이언트의 요구사항으로 게시글을 생성할 때 공개, 비공개 속성을 추가하게 되었을 경우 아래와 같은 SQL이 생성되게 된다. 

INSERT INTO Posts (title, content)
       VALUE ("제목", "내용");
       
       // visivility 속성값이 추가되기 전

INSERT INTO Posts (title, content, visibility)
       VALUE ("제목", "내용", "visible");
# 게시글의 visivility Column이 추가되었습니다.
     // visivility 속성값이 추가된 후

Javascript 코드 만으로는 게시글을 관리하는 테이블이 어떤 테이블을 나타내는지 인지하기도 어렵고, 모든 API에서 사용하는 Raw Query에서 visibility Column에 대한 내용을 하나씩 수정해야 한다.

단순히 조회를 하는 API 뿐만 아니라 생성, 수정, 삭제에 해당하는 모든 API를 해당하는 쿼리에 맞게 수정해야하는 불상사가 발생하게  된다. (프로젝트를 시작한지 얼마되지 않았다면 API를 수정하기 쉽겠지만, 사용하는 API가 수십, 수백개가 된다고 했을 때, 모든 코드를 수정하는 것이 쉽지 않다.)

여기서 ORM을 사용하였을 경우 테이블을 나타내는 Prisma의 model을 수정하기만 하더라도 수많은 API에서 Raw Query를 수정하지 않고도 visibility Column 값에 대한 정보를 추가할 수 있다.

 

그러나, ORM도 만능은 아니다. 단점이 존재한다.

 

JOIN과 UNION 연산자를 동시에 사용하는 복잡한 쿼리를 작성할 경우, ORM으로 구현하기 위해 SQL 보다는 ORM을 더 깊게 이해해야 하는 상황이 발생할 수 있고, 이로인해 원인과 결과가 뒤집힌 상황이 발생할 수도 있다.

또한, 서브 쿼리를 포함하는 복잡한 쿼리를 작성하거나, ORM의 SQL로 변환해주는 시간 조차 아까운 극한의 성능을 요구하는 쿼리가 필요한 상황에서는 Raw Query를 사용하는 것이 더욱 좋을 수 있다.