ORM과 Prisma

1. ORM과 Prisma

• 1) Prisma란?
  💡 Prisma는 ORM(Object Relational Mapping)으로써 Javascript 객체(Object)와 데이터베이스의 관계(Relation)을 연결(Mapping) 해주는 도구
  
• 2) Prisma vs 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)은 동일한 위상을 가지고 있습니다.
3) 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 ("제목", "내용");

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

  우선 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를 사용하는 것이 더욱 좋을 수 있답니다.