Prisma ORM 을 사용한 RDB Data modeling

Prisma ORM 을 사용해, 관계형 데이터베이스 (Relational Database) 데이터 모델링 경험에 관한 글입니다.

얼마전부터 새로 시작한 프로젝트에서, 서비스를 처음부터 참여하여 만들게 되었다. 기획 단계에서 기획자, 디자이너, 동료 개발자와 함께 Application 에서 누가, 무엇을, 어떻게 할 지 등에 이야기하다보니, DB 에 어떤 것들을 넣어야 하는 지 감이 왔다.

만들고 있는 서비스는 SNS 서비스라, 주로 기획단에서 이러한 이야기들이 오갔다.

"어드민이 포스트를 올리면, 그 밑에 유저들이 의견을 이슈로 달아주고, 또 다른 유저들이 이슈에 댓글을 달았으면 좋겠습니다. ...."

데이터 모델링을 할 때는, application 의 main entitiy 들을 정해야 하는데, 위 짧은 말에서도 이미 5개의 엔티티가 나온 셈이다.

이번 프로젝트에서는 관계형 데이터베이스를 선택했는데, 사실 MongoDB 같은 NoSQL 을 써보고도 싶었으나, 데이터 엔티티들 간의 관계가 명확했고 대부분의 엔티티들이 서로 종속된 관계였기 때문이다.

Prisma ORM 을 선택한 이유

sql 을 직접 날려 table 구조 위주로 프로그래밍하는 것보다 객체 지향적인 프로그래밍을 해보고 싶었고, 동료 개발자와 프론트 단에서도 타입스크립트를 사용해 객체 단위에서 심도있게 공부하며 개발해보자는 목표가 있었기에, 백엔드 단에서도 데이터 모델링 객체 위주로 할 수 있게 ORM 이 도와주기 때문이다.

어떤 점에서 객체 지향적인 데이터 모델링에 도움이 되던가?

Prisma 를 사용하면, prisma schema 라는 파일에서만 db 와의 연결이 이루어진다. 이 파일에서 데이터 모델링을 하는데, 이미 sql 로 생성된 테이블들을 introspect 하여 prisma schema 에 반영하는 데이터 레벨 단위의 방법과, 객체 지향적으로 생각하여 prisma schema 에 데이터 모델링을 직접 하여 migrate 를 통해 table 을 생성하는 방법이 있다.

바로 이 두 번째 migrate 를 할 때, 개발자는 schema 를 직접 작성하며 엔티티들의각 필드 타입, 엔티티 간의 관계에 관해 굉장히 많은 고민을 하게 된다. (경험담이다.)

또한, query 를 실행하여 data 를 읽고, 수정하는 단계에서도 ORM 을 사용하면 직접 sql 을 날리는 것이 아니라, 추상화를 통해 개발자가 prisma.user.findMay 이런 식으로 object 처럼 생각할 수 있게 도와준다. 이는 생 query 를 써서 'SELECT * from USER where ~' 식으로 하는 것과는 생각하는 방향이 달라진다.