학습 목표
- 사용자·프로젝트·댓글 데이터 설계의 역할과 적용 조건을 설명할 수 있다.
- 화면마다 필요한 조회와 정렬·필터를 적으세요.
- 작은 샘플에서 구조 변경과 복구 절차를 확인하세요.
사전 지식
앞선 Firebase와 Supabase 비교하기를 먼저 읽으면 용어를 이해하기 쉽습니다. 이미 아는 내용이면 이 장부터 시작해도 됩니다.
개념 이해
데이터 모델링은 장부에 어떤 항목을 어떤 관계로 기록할지 정하는 일입니다. 먼저 화면에서 필요한 조회를 적은 뒤 키·관계·인덱스를 설계하면 데이터가 늘어도 전체를 매번 읽지 않을 수 있습니다.
컬렉션·문서와 테이블·행
문서는 항목 하나를 묶고 컬렉션은 같은 종류를 모읍니다. 관계형 DB는 테이블의 행과 열로 데이터를 관리합니다.
기본키·외래키·관계
기본키는 한 항목을 식별하고 외래키는 다른 항목과 연결합니다. 사용자 ID와 표시 이름을 혼동하지 말고 이름이 바뀌어도 관계가 유지되게 합니다.
정규화와 비정규화
정규화는 중복을 줄여 변경의 일관성을 지키고, 비정규화는 읽기 편의를 위해 일부 복제합니다. 복제한다면 원본과 갱신 책임을 정해야 합니다.
인덱스·페이지네이션·검색
인덱스는 조건에 맞는 기록을 찾는 목차입니다. 목록은 안정적인 정렬과 커서를 사용하고 전문 검색은 DB의 지원 범위를 넘어서는지 확인합니다.
검증·중복·마이그레이션
필수 필드·타입·길이를 검사하고 좋아요 같은 중복 작업은 고유키로 막습니다. 구조 변경은 버전·백업·이행 순서·복구 계획을 갖춘 마이그레이션으로 진행합니다.
실제 사용 사례
users/UID, projects/ID, projects/ID/comments/ID를 연결하고 좋아요 ID는 사용자와 프로젝트 조합으로 정할 수 있습니다. 사용자 삭제 시 댓글·좋아요·파일을 어떻게 처리할지도 관계의 일부입니다.
단계별 실습
실습은 운영 서비스가 아닌 별도 연습 프로젝트에서 진행하세요. 기존 파일이 있다면 변경 전 기록을 남깁니다.
- 화면마다 필요한 조회와 정렬·필터를 적으세요.
- 사용자·프로젝트·댓글·좋아요의 고유키와 소유자를 정하세요.
- 읽기 경로별 인덱스와 커서 페이지네이션을 설계하세요.
- 중복 생성·수정·탈퇴 시 정합성 규칙을 적으세요.
- 작은 샘플에서 구조 변경과 복구 절차를 확인하세요.
코드와 프롬프트
아래 코드는 DB 제품과 무관하게 논리 구조를 그리는 환경의 예시입니다. 실제 프로젝트의 버전과 기존 구성을 확인한 뒤 필요한 부분만 적용하세요.
users: id, displayName
projects: id, ownerId -> users.id, title, createdAt
comments: id, projectId -> projects.id, ownerId -> users.id, body
likes: unique(projectId, userId)아래 요청에서 대괄호 부분을 내 프로젝트에 맞게 바꾼 뒤 AI 도구에 전달하세요.
[서비스]의 사용자·프로젝트·댓글·좋아요를 설계해줘. 화면별 조회, 기본키/외래키, 소유권, 인덱스, 페이지네이션, 검색, 중복 방지, 검증, 삭제와 마이그레이션 계획을 포함해줘.자주 발생하는 문제와 해결
| 문제와 원인 | 해결 방법과 확인 기준 |
|---|---|
| 이름을 키로 써서 변경 시 관계가 끊김 | 변하지 않는 고유 ID로 연결합니다. |
| 조회가 느려진 뒤 모든 데이터를 복제함 | 조회 계획과 비용을 측정하고 필요한 요약만 복제합니다. |
핵심 요약
- 데이터 구조는 조회와 변경 양쪽을 만족해야 합니다.
- 중복과 삭제 관계도 처음에 정의합니다.
완료 확인
참고자료
확인 기준일: 2026-10-20. 요금·사용 한도·제품 기능·설정 경로는 변경될 수 있으므로 작업 직전 공식 문서와 설치 버전을 확인하세요.