postgresql-table-design
전문가의 PostgreSQL 스키마 설계 가이드
PostgreSQL 스키마 설계는 데이터 타입, 인덱싱 전략, 제약조건 및 성능 패턴에 대한 지식을 필요로 합니다. 이 스킬은 PostgreSQL 전용 모범 사례, 고급 기능 및 일반적인 함정을 포괄적으로 안내하여 효율적이고 유지 관리 가능한 데이터베이스 스키마를 구축하는 것을 도와줍니다.
스킬 ZIP 다운로드
Claude에서 업로드
설정 → 기능 → 스킬 → 스킬 업로드로 이동
토글을 켜고 사용 시작
테스트해 보기
"postgresql-table-design" 사용 중입니다. PostgreSQL에서 통화 값을 어떻게 저장해야 합니까?
예상 결과:
통화 값에는 NUMERIC(p,s)을 사용하고, float 타입은 절대 사용하지 마세요. 예를 들어: 소수점 둘째 자리까지 있는 통화의 경우 amount NUMERIC(10,2). 이렇게 하면 부동소수점 정밀도 문제 없이 정확한 10진 산술 연산을 제공합니다. deprecated된 money 타입은 사용하지 마세요.
"postgresql-table-design" 사용 중입니다. BIGINT GENERATED ALWAYS AS IDENTITY와 UUID의 기본 키 차이점은 무엇입니까?
예상 결과:
- BIGINT GENERATED ALWAYS AS IDENTITY: 순차 정수 ID. 대부분의 사용 사례에 선호됩니다. 장점: 더 작은 저장 공간, 더 빠른 인덱싱, 더 좋은 지역성. 시스템 간 전체 고유성이 필요하지 않을 때 사용하세요.
- UUID: 전역적으로 고유한 식별자. 여러 데이터베이스의 데이터 병합, 연합 시스템 필요시 또는 불투명하고 비순차적 ID가 필요할 때 사용하세요. PostgreSQL 18+에서는 uuidv7()으로, 이전 버전에서는 gen_random_uuid()로 생성하세요.
"postgresql-table-design" 사용 중입니다. 외래 키 열에 인덱스를 추가해야 합니까?
예상 결과:
네, 외래 키 열에 항상 명시적 인덱스를 추가하세요. PostgreSQL은 일부 데이터베이스와 달리 FK 열을 자동으로 인덱싱하지 않습니다. 이렇게 하면 조인이 빨라지고 부모 테이블 삭제 또는 업데이트 시 잠금 문제를 방지할 수 있습니다. 예: user_id 외래 키에 대해 CREATE INDEX ON orders (user_id).
보안 감사
안전This skill is a documentation-only resource providing PostgreSQL schema design guidance. All 237 static findings are false positives triggered by SQL examples and technical terminology in markdown code blocks. The skill contains no executable code, network calls, or file system access. Safe for publication.
품질 점수
만들 수 있는 것
새 데이터베이스 스키마 설계
애플리케이션용 새 PostgreSQL 데이터베이스를 설계할 때 테이블 구조, 데이터 타입, 제약조건 및 인덱싱 전략에 대한 안내를 받으세요.
기존 스키마 성능 최적화
쿼리 성능을 개선하고 데이터베이스 팽창을 줄이기 위한 인덱싱 전략, 파티셔닝 옵션 및 성능 패턴에 대해 알아보세요.
스키마 설계 결정 검토
구현 전에 PostgreSQL 모범 사례에 대해 데이터 타입 선택, 제약조건 사용 및 정규화 결정을 검증하세요.
이 프롬프트를 사용해 보세요
이메일, 이름 및 타임스탬프가 있는 users 테이블을 만들어야 합니다. 권장되는 PostgreSQL 스키마는 무엇입니까?
제품 가격, IP 주소 및 사용자 기본 설정을 저장하고 있습니다. 어떤 PostgreSQL 데이터 타입을 사용해야 합니까?
내 orders 테이블은 user_id, status 및 created_at으로 필터링하는 쿼리가 있습니다. 어떤 인덱스를 만들어야 합니까?
매일 수백만 개의 센서 읽기 값을 저장해야 하며 디바이스와 시간 범위로 필터링하는 쿼리가 있습니다. 스키마와 파티셔닝을 어떻게 설계해야 합니까?
모범 사례
- 3차 정규형으로 정규화된 스키마로 시작하고 특정 고가치 쿼리로 측정된 성능 문제가 있는 경우에만 비정규화하세요
- 모든 타임스탬프 열에는 TIMESTAMPTZ를, 문자열에는 TEXT를, 돈에는 NUMERIC을, 기본 키에는 UUID가 필요하지 않은 한 BIGINT GENERATED ALWAYS AS IDENTITY를 사용하세요
- WHERE 절, JOIN 조건 및 ORDER BY 절에 사용되는 열에 인덱스를 만들고, 외래 키 열에는 항상 명시적 인덱스를 추가하세요
피하기
- VARCHAR(n) 또는 CHAR(n) 데이터 타입을 사용하지 마세요. 필요한 경우 CHECK 제약조건과 함께 TEXT를 사용하세요
- TIMESTAMP without time zone, money 타입 또는 SERIAL을 사용하지 말고, 대신 TIMESTAMPTZ, NUMERIC 및 GENERATED ALWAYS AS IDENTITY를 사용하세요
- 실제 성능 문제를 측정하기 전에 데이터를 prematurely denormalize하지 마세요. 과도한 비정규화는 입증된 이점 없이 유지 관리 부담만 생성합니다