초보개발자 DB설계기준(from 지피티)

 

 

초보 개발자 기준으로 DB 설계는 “요구사항 → 데이터(엔티티) → 관계 → 제약/정규화 → 인덱스/성능 → 물리 구현” 순서로 가면 안전해요.

 

 

1) 요구사항을 문장으로 정리
“무엇을 저장해야 하지?”를 먼저 확정
화면/기능 목록을 적고, 각 기능에서 입력/조회/수정/삭제되는 데이터를 뽑기
예: 회원가입(이메일, 비번, 이름), 주문(주문번호, 결제금액, 배송지) …

 

 

2) 핵심 용어를 ‘명사’로 뽑아서 엔티티 후보 만들기
문장에서 명사 = 테이블 후보
예: 사용자, 상품, 주문, 주문항목, 결제, 배송, 쿠폰 …

 

3) 각 엔티티의 속성(컬럼) 정의
“이 테이블은 어떤 정보를 가져야 하지?” 체크
컬럼마다
타입(문자/숫자/날짜)
필수 여부(NULL/NOT NULL)
유일성(UNIQUE)
기본값(DEFAULT)
의미/범위(코드값, 길이)
를 적어둠

 

 

4) PK(기본키) 결정
보통 초보는 surrogate key(자동 증가 ID) 추천
자연키(이메일, 주민번호 등)는 변경/정책에 취약할 수 있어 보조로 UNIQUE로 두는 편이 안전

 

 

5) 테이블 간 관계 정의 (1:1 / 1:N / N:M)
1:N: N쪽 테이블에 FK 둠 (주문 ↔ 주문항목)
N:M: 중간 테이블 만들어야 함 (상품 ↔ 태그 → 상품태그)

 

 

6) 정규화(중복 제거) + 현실적 타협 지점 찾기
중복된 값(예: 사용자 주소를 주문에도 또 저장?)은 원칙상 분리
다만 주문처럼 “그 시점의 주소 스냅샷”이 필요하면 의도적으로 중복 저장(정규화보다 비즈니스가 우선)

 

초보 체크 기준:
한 컬럼에 값 여러 개 넣지 않기(“A,B,C” 금지)
반복되는 그룹은 별도 테이블로 빼기

 

 

7) 제약조건/규칙을 DB에 박기
FK(참조 무결성), ON DELETE/UPDATE 정책
CHECK(상태값 범위), UNIQUE
상태머신이 있으면 상태값/전이 규칙을 문서로라도 고정

 

 

8) 조회 패턴 기준으로 인덱스 설계
“어떤 화면/쿼리가 제일 자주 돌지?”부터

인덱스는 보통
FK 컬럼
자주 WHERE/GROUP BY/ORDER BY 되는 컬럼
(조합 인덱스) where 조건 순서대로 부터 시작

주의: 인덱스는 쓰기(INSERT/UPDATE) 비용도 올림 → 많이 만들면 느려짐

 

 

 

9) 데이터 양/성장/보관 정책 결정
1년치만? 영구 보관?
로그/이력 테이블 분리
대용량이면 파티셔닝/아카이빙 전략 고려

 

 

 

10) 물리 구현 (DDL 작성) → 샘플 데이터 → 쿼리 검증
CREATE TABLE 먼저 만들고
더미데이터 넣어서
실제 화면 쿼리/리포트 쿼리 돌려보고
느리면 인덱스/구조 재조정

 

 

11) 마이그레이션/버전관리 붙이기(초보도 강추)
“나중에 컬럼 추가/변경”이 반드시 생김
Flyway/Liquibase 같은 도구 또는 최소한 DDL 파일 버전관리

 

 

 

초보가 특히 자주 실수하는 포인트 5개
“상태값”을 문자열로 막 넣고 통제 안 함 → 코드/ENUM/테이블로 관리
컬럼 하나에 리스트 저장(콤마로) → 중간 테이블로
FK/제약조건 없이 앱에서만 체크 → 데이터 꼬임
인덱스 없이 대용량 가정 → 나중에 화면 다 느려짐
“주문 당시 가격/주소” 같은 스냅샷 필요성을 놓침