Compétences database-design
📦

database-design

Sûr

데이터베이스 설계와 스키마 결정 마스터하기

개발자들은 데이터베이스 선택과 스키마 설계의 함정에서 어려움을 겪습니다. 이 스킬은 상황에 맞는 데이터베이스 선택, 스키마 설계, 쿼리 최적화를 위한 의사결정 프레임워크를 가르칩니다.

Prend en charge: Claude Codex Code(CC)
🥉 76 Bronze
1

Télécharger le ZIP du skill

2

Importer dans Claude

Allez dans Paramètres → Capacités → Skills → Importer un skill

3

Activez et commencez à utiliser

Tester

Utilisation de "database-design". I need to choose a database for a real-time chat application with 10,000 concurrent users, global distribution, and sub-50ms latency requirements.

Résultat attendu:

전 세계 분산과 엄격한 지연 시간 요구가 있는 실시간 채팅이라면, 상태/메시지 메타데이터용으로 Turso(엣지 SQLite)를 고려하고, 내구성 있는 저장을 위해 기본 PostgreSQL 인스턴스를 결합하세요. Turso는 엣지 배포로 지연 시간을 줄이고, PostgreSQL은 복잡한 쿼리와 트랜잭션을 처리합니다. 대안: 글로벌 브랜칭이 가능한 MySQL 호환성의 PlanetScale.

Utilisation de "database-design". Should I normalize my user preferences table or store as JSONB?

Résultat attendu:

다음의 경우 JSONB로 저장하세요: 선호도가 개별적으로 거의 조회되지 않고, 스키마가 자주 변하며, 항상 전체 세트를 가져오는 경우. 다음의 경우 정규화하세요: WHERE 절에서 특정 선호도를 조회해야 하거나, 선호도별로 업데이트 빈도가 다르거나, 외래 키 제약조건이 필요한 경우. 하이브리드 접근: 유연한 선호도는 JSONB로, 자주 필터링되는 설정은 정규화 테이블로.

Audit de sécurité

Sûr
v1 • 2/24/2026

All static analyzer findings are false positives. The 'external_commands' detections are markdown code fence blocks (```) used for educational diagrams, not executable shell commands. The 'weak cryptographic algorithm' flags reference UUID/ULID discussions in documentation context. The schema_validator.py is a legitimate local Python script for Prisma schema validation. This is a documentation-only skill teaching database design principles.

8
Fichiers analysés
489
Lignes analysées
0
résultats
1
Total des audits
Aucun problème de sécurité trouvé
Audité par: claude

Score de qualité

45
Architecture
100
Maintenabilité
87
Contenu
50
Communauté
100
Sécurité
91
Conformité aux spécifications

Ce que vous pouvez construire

새 프로젝트 데이터베이스 설정

MVP를 만드는 스타트업 창업자는 PostgreSQL, SQLite, 서버리스 옵션 중 무엇을 선택할지 안내가 필요합니다. 이 스킬은 확장성 요구, 예산, 배포 선호도에 기반한 의사결정 트리를 제공합니다.

스키마 설계 리뷰

새 기능을 설계하는 백엔드 엔지니어는 사용자 관계, 타임스탬프, 외래 키 제약조건 모델링에 대한 도움이 필요합니다. 이 스킬은 정규화의 트레이드오프와 관계 패턴을 검토합니다.

쿼리 성능 문제 해결

느린 쿼리를 겪는 개발자는 인덱싱 전략과 N+1 문제를 이해해야 합니다. 이 스킬은 EXPLAIN ANALYZE 해석과 복합 인덱스 설계를 설명합니다.

Essayez ces prompts

초급: 데이터베이스 선택 
{project_type} 애플리케이션을 만들고 있으며 예상 사용자 수는 {expected_users}명입니다. 예산은 {budget_level}이고 {specific_requirements}가 필요합니다. 데이터베이스 선택 가이드를 바탕으로 최적의 데이터베이스 옵션을 추천하고 트레이드오프를 설명해 주세요.
중급: 스키마 설계 리뷰 
{table_name} 테이블의 스키마 설계를 리뷰해 주세요. {data_fields}를 저장하고 {related_tables}와의 관계가 필요합니다. 제 접근이 정규화 원칙을 따르는지, 적절한 인덱스를 갖추었는지, 올바른 관계 유형을 사용하는지 확인해 주세요.
고급: 쿼리 최적화 
{query_description}에 대한 쿼리가 {execution_time}가 걸립니다. 다음은 EXPLAIN ANALYZE 출력입니다: {explain_output}. 병목 지점을 식별하고 구체적인 인덱싱 또는 쿼리 재구성 전략을 추천해 주세요.
전문가: 마이그레이션 전략 
다운타임 없이 {current_schema}에서 {target_schema}로 마이그레이션해야 합니다. 테이블에는 {row_count}개의 행이 있으며 {traffic_level} 수준의 트래픽을 처리합니다. 마이그레이션 가이드의 기법을 사용해 전략을 설계해 주세요.

Bonnes pratiques

  • 타임존 인식을 위해 TIMESTAMPTZ로 created_at과 updated_at 타임스탬프를 항상 정의
  • 분산 시스템에서는 UUID 또는 ULID 기본 키를 사용해 열거 공격을 피하고 오프라인 ID 생성을 가능하게 함
  • 가장 일반적인 쿼리 패턴에 맞춰 복합 인덱스를 만들되, 동등 조건 컬럼을 범위 조건 컬럼보다 먼저 배치

Éviter

  • 간단한 애플리케이션에서 SQLite로 충분한데도 PostgreSQL을 기본으로 선택해 불필요한 인프라 복잡성을 추가
  • 쓰기 성능 영향과 낮은 카디널리티 비효율을 고려하지 않고 모든 컬럼에 인덱스를 생성
  • 프로덕션 쿼리에서 필요한 컬럼을 명시적으로 선택하지 않고 SELECT * 사용

Foire aux questions

SQLite 대신 PostgreSQL을 선택해야 하는 시점은 언제인가요?
SQLite를 선택할 경우: 임베디드 애플리케이션, 로컬 개발, 하루 100K 요청 미만의 읽기 중심 워크로드, 단일 작성자 시나리오, 또는 기능보다 단순성이 더 중요할 때. PostgreSQL을 선택할 경우: 동시 쓰기, 고급 SQL 기능(CTEs, 윈도우 함수), 행 수준 보안, 복잡한 트랜잭션, 또는 계보와 감사 추적이 필요할 때.
N+1 쿼리 문제는 무엇이며 어떻게 해결하나요?
N+1은 부모 레코드를 가져오는 1개의 쿼리 후, 관련 레코드를 가져오기 위해 N개의 쿼리를 반복 실행할 때 발생합니다. 해결 방법: JOIN으로 데이터를 한 쿼리로 결합, ORM의 eager loading, GraphQL에서 배치를 위한 DataLoader, 또는 모든 관련 레코드를 한 번에 가져오는 서브쿼리. 수정이 효과적인지 항상 EXPLAIN ANALYZE로 검증하세요.
Drizzle, Prisma, Kysely 중 어떻게 선택하나요?
Drizzle: 가볍고 SQL과 유사한 문법, 서버리스/엣지에 적합. Prisma: 마이그레이션, 타입 생성, 스튜디오 UI를 포함한 풀스펙 ORM. Kysely: 엄격한 타입 안전성을 갖춘 TypeScript 중심 쿼리 빌더. 최소주의는 Drizzle, 전체 ORM 기능은 Prisma, ORM 추상화 없이 타입 안전한 쿼리 빌딩은 Kysely를 선택하세요.
최적의 성능을 위해 어떤 컬럼에 인덱스를 만들어야 하나요?
인덱싱할 컬럼: WHERE 절의 필터링, JOIN 조건, ORDER BY 정렬, 관계 쿼리를 위한 외래 키 컬럼. 인덱싱을 피할 컬럼: 낮은 카디널리티 컬럼(불리언, 성별), 쿼리에서 거의 사용되지 않는 컬럼, 또는 쓰기 트래픽이 많아 인덱스 유지 비용이 삽입을 느리게 만드는 테이블.
다운타임 없이 큰 테이블을 안전하게 마이그레이션하려면 어떻게 해야 하나요?
확장-축소 패턴을 사용하세요: 1단계(확장)에서 새 컬럼/테이블을 추가하고 기존은 유지. 2단계에서 데이터를 백필하고 이중 쓰기. 3단계에서 읽기를 점진적으로 이전. 4단계(축소)에서 검증 후 기존 컬럼/테이블 제거. 백필은 잠금 경합을 피하기 위해 배치 처리하고, 점진적 롤아웃에는 기능 플래그를 사용하세요.
Neon, Supabase, 자체 호스팅 PostgreSQL의 차이는 무엇인가요?
Neon: git 같은 데이터베이스 브랜칭, 자동 확장, 사용량 기반 과금이 있는 서버리스 PostgreSQL. Supabase: 실시간 구독, 인증, 스토리지, 엣지 함수가 포함된 PostgreSQL 기반 백엔드 플랫폼. 자체 호스팅: 구성, 확장, 비용에 대한 완전한 제어가 가능하지만 운영 전문성이 필요. 서버리스는 Neon, 풀스택 기능은 Supabase, 제어는 자체 호스팅을 선택하세요.

Détails du développeur

Auteur

sickn33

Licence

MIT

Dépôt

https://github.com/sickn33/antigravity-awesome-skills/tree/main/skills/database-design

Réf

main

Structure de fichiers

📁 scripts/

📄 schema_validator.py

📄 database-selection.md

📄 indexing.md

📄 migrations.md

📄 optimization.md

📄 orm-selection.md

📄 schema-design.md

📄 SKILL.md