Table이다 (아니다)
새롭게 프로젝트를 목표로 시작했으니, 데이터에 대한 테이블을 만들때가 되었다.
ERD를 토대로 만들어야하는데, 데이터의 테이블을 만드는건 다양한 방법이 있었다.
Model : Database에서 테이블을 나타내는 객체
현재까지 알고있는 Sequelize에서 sequelize.define을 이용하여 모델을 정의 한 적도 있었고.
Prisma를 사용하여 모델을 직접 정의를 해본 적도 있었다.
// schema.prisma
model User {
id Int @id @default(autoincrement())
username String @unique
email String @unique
posts Post[]
}
model Post {
id Int @id @default(autoincrement())
title String
content String
userId Int
user User @relation(fields: [userId], references: [id])
}Prisma를 처음 사용할 때에 '관계' 라는 것에 대해 직관적으로 보게되었으며, NestJs를 사용하는 마지막 프로젝트에서는 TypeOrm을 사용하여 Entity라는 것을 만들 예정이다.
개인적인 소견이지만 sequelize에서 적었던 양식 + 프리즈마에서 사용하였던 관계를 기재하는 방식을 더한 것이 TypeOrm entity를 만들때 사용하는 것 이 아닐까? 하는 생각을 가져보았다.
(일부 예시)
class 'UsersModel' 이라는 이름을 지어준 클래스 내부에서 프리즈마를 사용한 것과 크나큰 차이가 있지는 않지만, 하나의 entity를 각각의 테이블로 구성을 하고있으며 들어가는 컬럼에 대해서 표시 할 수 있다.
NestJs를 접하고 TypeOrm을 접하면서 일어난 변화는 생각보다 많은 데코레이터들을 제공하고 있어, @isNotEmpty라던지 최소한의 아주 작은 조건들에 대한 제약도 걸 수 있어서 편하다는 생각이 들었다.
TS를 위한 ORM 라이브러리로써 타입스크립트를 기본적으로 100%지원한다는 점에서 코드의 타입 안정성을 늘려, 추후에 작성할 비즈니스 로직 (controller, service 등.) 에서
' 우리는 userId를 number로 기대했는데 너는 object로 보냈군?' 과같은 nodeJS에서 골백번은 마주했었을 그 오류를 없앨 수 있다.
Decorator를 이용해서 모델을 간단하게 정의할 수 있다.
즉 코드가 간결해진다.
쿼리빌더 및 쿼리 작성에 대해 간편한 부분이 있어, 직접적으로 코드로 건드리기 어려운 부분 혹은 직관적 문법을 통해 간단한 쿼리를 작성 할 수도 있을것이다.
현재 초보 개발자들을 위한 커뮤니티 라는 주제로 회원에 대한 기능을 전반적으로 맡게되면서 기존에도 프로젝트를 진행해 본적은 있지만, '유저의 role(역할), 역할에 따른 그 해당 유저의 소속 회사(company), 유저의 기술스택 등 다양한 테이블이 유기적으로 연결되어 기능으로 동작해야하는 부분으로써 엔티티를 작성하고 간단한 기능들을 작성해 보았다.
( 우스갯소리로 친구가 보내준 관계도. 타 프로젝트들을 구경하면 ERD가 저것보다 복잡해지는걸 보았다. entity가 얼마나 복잡해질까?)
