[Refactor] Prisma 스키마 네이밍 컨벤션 정리

[JangDongHo]

close #20

⏳ 리뷰 예상 시간

5분

🛠 작업 사항

❌ 문제

model Question {
  id                Int       @id @default(autoincrement())
  user_id           Int
  like_count        Int       @default(0)
  view_count        Int       @default(0)
}

• Prisma 모델 필드명이 DB 컬럼 네이밍(snake_case)을 그대로 사용하고 있어요.
• 이로 인해 타입스크립트 코드에서 camelCase 컨벤션을 사용하지 못하고 snake_case 기반으로 쿼리를 작성해야 하는 문제가 생겨요.

✅ 리팩토링

model Question {
  id                Int       @id @default(autoincrement())
  userId            Int       @map("user_id")
  likeCount         Int       @default(0) @map("like_count")
  viewCount         Int       @default(0) @map("view_count")
}

• 따라서 Prisma 모델 필드명을 camelCase로 통일해서 코드 컨벤션을 지켰어요.
• 그리고 @map을 사용해 기존 DB snake_case 컬럼과 안전하게 매핑되도록 했어요.

⭐️ 리뷰 포인트

• Prisma 스키마 네이밍 컨벤션 리팩토링 방식이 적절한지 봐주시면 감사하겠습니다~~!

✅ 작업 체크리스트

• Prisma 모델 필드명을 camelCase로 통일
• 기존 DB snake_case 컬럼과의 호환을 위해 @map, @@map 적용

[whateveriiwant]

수고하셨습니다 🧆

[whateveriiwant]

DB 마이그레이션용 파일인가요?

[JangDongHo]

넵 DB 마이그레이션용 파일 맞습니다!
PR 설명에서 해당 부분을 놓쳤네요 😅

처음에는 마이그레이션 파일을 .gitignore 로 관리해야 하나 고민했는데, 개발 환경에서 팀원들마다 동일한 DB 상태를 재현하기 위해 레포지토리에 포함하는 것이 맞다고 판단했습니다!

다만, 스키마가 변경될 때마다 마이그레이션 파일이 추가되는 구조라서 이를 어떻게 하면 효율적으로 관리할 수 있을지에 대한 논의가 필요해보여요!

[LimSR12]

다만, 스키마가 변경될 때마다 마이그레이션 파일이 추가되는 구조라서 이를 어떻게 하면 효율적으로 관리할 수 있을지에 대한 논의가 필요해보여요!

오 저도 이 부분이 안그래도 궁금해서 AI에게 방금 물어봤는데, 다음과 같은 이유들로 migrations 폴더가 커져도 괜찮다고 하네요?! 물론 이건 AI의 답변일 뿐이라 추가적으로 조금 더 찾아보고 학습해봐야 하겠지만요!

2) migrations 폴더가 커져도 보통 문제 없는 이유

(1) 파일 크기가 작습니다

migration.sql은 대개 ALTER TABLE, CREATE TABLE 같은 DDL 몇 줄 수준이라
대부분 수 KB ~ 수십 KB 정도입니다.

(2) 실행 시 전체를 매번 재실행하지 않습니다

운영 배포에서 prisma migrate deploy는

• DB의 _prisma_migrations 테이블을 보고
• 아직 적용 안 된 마이그레이션만 순서대로 적용합니다.

이미 적용된 옛날 마이그레이션이 “성능 비용”으로 매번 재실행되는 구조가 아닙니다.

(3) Git 저장소 크기도 일반적으로는 안정적입니다

마이그레이션이 100개, 300개 쌓여도 텍스트 파일이어서 대개 큰 부담이 아닙니다.

[LimSR12]

고생 많으셨습니다 !! 👍

[LimSR12]

BIGINT 에서 INTEGER 로 변경하면서 경고 메시지가 생긴 것 같은데, id 를 INTEGER 로 변경하신 이유가 따로 있을까요?!

[leeHB-1007]

저도 위에 20260101084425 에서는 INT -> BIGINT로 변경했는데
여기서 다시 BIGINT -> INT로 변경했는지 궁급합니다~

[JangDongHo]

아이고 이 부분도 PR 문서에 설명이 누락되어 있어 혼동을 드렸군요.

DB 설계상의 의도 변경이라기보다는, ORM 사용 과정에서 발생한 런타임 이슈를 우회하기 위한 선택이었습니다!

만약 BigInt를 사용한다면 문서와 같이 해결할 수 있을 것 같은데, 이 부분은 저 혼자 결정할 수 있는 부분이 아닌 것 같아서 회의 시간에 다시 논의해보면 좋을 것 같아요.

[LimSR12]

다만, 스키마가 변경될 때마다 마이그레이션 파일이 추가되는 구조라서 이를 어떻게 하면 효율적으로 관리할 수 있을지에 대한 논의가 필요해보여요!

오 저도 이 부분이 안그래도 궁금해서 AI에게 방금 물어봤는데, 다음과 같은 이유들로 migrations 폴더가 커져도 괜찮다고 하네요?! 물론 이건 AI의 답변일 뿐이라 추가적으로 조금 더 찾아보고 학습해봐야 하겠지만요!

2) migrations 폴더가 커져도 보통 문제 없는 이유

(1) 파일 크기가 작습니다

migration.sql은 대개 ALTER TABLE, CREATE TABLE 같은 DDL 몇 줄 수준이라
대부분 수 KB ~ 수십 KB 정도입니다.

(2) 실행 시 전체를 매번 재실행하지 않습니다

운영 배포에서 prisma migrate deploy는

• DB의 _prisma_migrations 테이블을 보고
• 아직 적용 안 된 마이그레이션만 순서대로 적용합니다.

이미 적용된 옛날 마이그레이션이 “성능 비용”으로 매번 재실행되는 구조가 아닙니다.

(3) Git 저장소 크기도 일반적으로는 안정적입니다

마이그레이션이 100개, 300개 쌓여도 텍스트 파일이어서 대개 큰 부담이 아닙니다.

[DevJunz]

고생핬슴다
규칙에 잘 맞게 변경하신 것 같아요

[DevJunz]

여기서 왜 제약조건이랑 index를 드랍했다가 다시 설정하는지가 궁금해요
이 부분만 설명 부탁해요~

[JangDongHo]

제 생각에는 PK와 FK의 타입을 BIGINT에서 INT형으로 변경하면서 그와 관련된 제약조건과 index를 모두 다 지웠다가 다시 설정한게 아닌가 싶네요!