현문hyun답
[현문hyun답] 언제 어떤 데이터베이스와 ORM/ODM을 사용하는게 좋을까? (2) - ORM/ODM
Hyun-danpung2
2024. 11. 15. 20:40
728x90
반응형
본론 - 2
Mongoose
- 개요
- MongoDB 전용 ODM
- 장점
- MongoDB의 모든 기능을 활용할 수 있음
- 스키마를 쉽게 정의하고 유효성 검사를 설정할 수 있음
- 쿼리 전후에 미들웨어를 추가하여 로직을 쉽게 확장할 수 있음
- 단점
- 비동기 처리 방식이 TypeORM이나 Prisma에 비해 덜 직관적임
- 쿼리 작성 시 코드가 복잡해 질 수 있음
Prisma
- 개요
- Typescript ORM
- 다양한 데이터베이스 지원
- 타입 안정성을 제공하고 데이터베이스 스키마를 선언적으로 정의할 수 있음
- 장점
- Typescript와 호환이 잘 되어 컴파일 시점에 오류를 잡을 수 있음
- 체이닝을 통한 간결한 쿼리 작성 가능
- 데이터베이스 스키마에 따라 자동으로 타입 생성
- 단점
- MongoDB의 모든 기능을 지원하지 않음
- 마이그레이션 충돌이나 관리가 복잡함
- 생성된 쿼리가 최적화 되어있지 않아 수동으로 최적화 해야할 수 있음
TypeORM
- 개요
- Typescript와 Javascript를 위한 ORM
- RDBMS와 NoSQL 모두 지원
- 장점
- 데코레이터 기반으로 코드가 깔끔함
- Active Record와 Data Mapper 패턴 중 선택하여 사용 가능
- 단점
- MongoDB에 대한 지원이 Mongoose보다 떨어질 수 있음
- 대규모 데이터베이스에서 성능 문제가 발생할 수 있음
Sequelize
- 개요
- Node 진영에서 사용하는 Promise 기반의 ORM
- Active Record 패턴
- 장점
- 직관적인 API를 제공함
- 데이터베이스 스키마 변경을 관리할 수 있는 마이그레이션 도구를 제공
- 단점
- 비동기 작업의 복잡성이 증가할 수 있음
- Active Record 패턴의 한계로 복잡한 비즈니스 로직을 처리하기 어려울 수 있음
결론
실제 프로젝트에서 겪었던 문제는 RDB로 시작했다가, 기획과 요구사항이 계속해서 수정되면서 사용하지 않지만 연관관계로 엮여 있어 그대로 둬야하거나, 1대 1로 엮이고 분명하게 하위 요소임에도 추가적으로 테이블을 생성해야하는 경우 등이 있었다. 다른 개발자가 프로젝트에 참여했을 때, 프로젝트의 모든 히스토리를 파악하고 작업해야 하거나 일정에 맞추기 위해 파악하지 못하고 작업하여 문제가 발생할 여지가 있어 NoSQL에 대한 미련이 생기는 경우가 있었다. 이 지경 즈음이 되면 이미 쌓여있는 데이터는 많고 다음 일정이 촉박하여 계속 문제를 떠안고 가야한다.
단순히 개발적인 요소만으로 기술을 선택하는 것은 개발자 동료 혹은 후임, 심지어 본인에게까지 폭탄을 돌리게 되는 행위일 수도 있다는 것을 깨달았고 경력이 쌓일 수록 개발 외적인 요소에 대한 통찰력이 필요함을 인지해야 할 것 같다.
728x90
반응형