Lar

Skill

Gerenciamento de banco de dados

database-designer

alirezarezvani/claude-skills

Projetar esquemas de banco de dados, planejar migrações de dados, otimizar consultas e modelar relações entre dados por meio de análises especializadas e ferramentas automatizadas.

...Expandir tudo

Tempo atualizado 29 de Agosto de 2026

# migration # sql # postgresql # normalization # database design # index optimization # mermaid erd # schema design

Desenvolvedor de Bancos de Dados - Habilidade de Nível AVANÇADO

Visão geral

Uma competência abrangente em projeto de bancos de dados que oferece recursos de análise, otimização e migração de nível especializado para sistemas modernos de bancos de dados. Essa competência combina princípios teóricos com ferramentas práticas para ajudar arquitetos e desenvolvedores a criar esquemas de bancos de dados escaláveis, de alto desempenho e fáceis de manter.

Competências Essenciais

Projeto e Análise de Esquemas

Análise de normalização: detecção automatizada de níveis de normalização (1NF a BCNF)
Estratégia de desnormalização: recomendações inteligentes para otimização de desempenho
Otimização de tipos de dados: identificação de tipos inadequados e problemas de tamanho
Análise de restrições: chaves estrangeiras ausentes, restrições de exclusividade e verificações de valores nulos
Validação de convenções de nomenclatura: Padrões consistentes de nomenclatura de tabelas e colunas
Geração de ERD: Criação automática de diagramas Mermaid a partir de DDL

Otimização de índices

Análise de lacunas de índices: Identificação de índices ausentes em chaves estrangeiras e padrões de consulta
Estratégia de índices compostos: ordenação ideal de colunas para índices com várias colunas
Detecção de redundância de índices: eliminação de índices sobrepostos e não utilizados
Modelagem do impacto no desempenho: estimativa de seletividade e análise de custo de consulta
Seleção do tipo de índice: índices B-tree, hash, parciais, de cobertura e especializados

Gerenciamento de migração

Migrações sem tempo de inatividade: implementação do padrão “expandir-contrair”
Evolução do esquema: adições, exclusões e alterações de tipo de coluna seguras
Scripts de migração de dados: transformação e validação automatizadas de dados
Estratégia de reversão: Recursos completos de reversão com validação
Planejamento de execução: etapas de migração ordenadas com resolução de dependências

Fluxo de trabalho da ferramenta (execute estes — não analise esquemas manualmente)

Todos os caminhos são relativos a esta pasta de habilidades; exemplos de entradas em assets/.

1. Analise o esquema

python3 schema_analyzer.py --input schema.sql --generate-erd --output-format json -o analysis.json

Aceita DDL SQL ou esquema JSON (assets/sample_schema.sql / sample_schema.json). A saída inclui resultados de normalização, restrições ausentes, problemas de nomenclatura e um ERD no Mermaid — mostre o ERD ao usuário e corrija os problemas sinalizados antes de otimizar.

2. Otimizar índices com base em padrões reais de consulta

python3 index_optimizer.py --schema assets/sample_schema.json --queries assets/sample_query_patterns.json --analyze-existing --format json -o indexes.json

Primeiro, grave as consultas mais frequentes do usuário em um JSON de padrões de consulta (copie assets/sample_query_patterns.json). O resultado é uma lista ordenada por prioridade de recomendações de CREATE INDEX, além da remoção de índices redundantes.

3. Gerar a migração

python3 migration_generator.py --current current_schema.json --target target_schema.json --zero-downtime --format sql -o migration.sql

--zero-downtime emite um plano de expansão-contração; --validate-only verifica a viabilidade sem gerar SQL.

4. Ciclo de verificação

Reexecute a etapa 1 no esquema de destino e verifique se os problemas encontrados na primeira passagem foram resolvidos; execute migration_generator.py --validate-only antes de entregar a migração.

Princípios de projeto de banco de dados

→ Consulte references/database-design-reference.md para obter detalhes

Melhores práticas

Projeto de esquema

Use nomes significativos: convenções de nomenclatura claras e consistentes
Escolha tipos de dados adequados: colunas com tamanho adequado para eficiência de armazenamento
Defina restrições adequadas: chaves estrangeiras, restrições de verificação, índices exclusivos
Leve em conta o crescimento futuro: planeje a escalabilidade desde o início
Documente as relações: relações claras de chaves estrangeiras e regras de negócios

Otimização de desempenho

Crie índices estrategicamente: abranja padrões comuns de consulta sem criar índices em excesso
Monitore o desempenho das consultas: faça análises regulares das consultas lentas
Particione tabelas grandes: melhore o desempenho das consultas e a manutenção
Utilize níveis de isolamento adequados: Equilibre consistência e desempenho
Implemente pool de conexões: utilização eficiente de recursos

Considerações de segurança

Princípio do privilégio mínimo: conceder apenas as permissões estritamente necessárias
Criptografe dados confidenciais: em repouso e em trânsito
Audite os padrões de acesso: monitore e registre o acesso ao banco de dados
Validar entradas: Prevenir ataques de injeção de SQL
Atualizações regulares de segurança: manter o software do banco de dados atualizado

Padrões de geração de consultas

SELECT com JOINs

-- INNER JOIN: only matching rows
SELECT o.id, c.name, o.total
FROM orders o
INNER JOIN customers c ON c.id = o.customer_id;

-- LEFT JOIN: all left rows, NULLs for non-matches
SELECT c.name, COUNT(o.id) AS order_count
FROM customers c
LEFT JOIN orders o ON o.customer_id = c.id
GROUP BY c.name;

-- Self-join: hierarchical data (employees/managers)
SELECT e.name AS employee, m.name AS manager
FROM employees e
LEFT JOIN employees m ON m.id = e.manager_id;

Expressões de tabela comuns (CTEs)

-- Recursive CTE for org chart
WITH RECURSIVE org AS (
  SELECT id, name, manager_id, 1 AS depth
  FROM employees WHERE manager_id IS NULL
  UNION ALL
  SELECT e.id, e.name, e.manager_id, o.depth + 1
  FROM employees e INNER JOIN org o ON o.id = e.manager_id
)
SELECT * FROM org ORDER BY depth, name;

Funções de janela

-- ROW_NUMBER for pagination / dedup
SELECT *, ROW_NUMBER() OVER (PARTITION BY customer_id ORDER BY created_at DESC) AS rn
FROM orders;

-- RANK with gaps, DENSE_RANK without gaps
SELECT name, score, RANK() OVER (ORDER BY score DESC) AS rank FROM leaderboard;

-- LAG/LEAD for comparing adjacent rows
SELECT date, revenue,
  revenue - LAG(revenue) OVER (ORDER BY date) AS daily_change
FROM daily_sales;

Padrões de agregação

-- FILTER clause (PostgreSQL) for conditional aggregation
SELECT
  COUNT(*) AS total,
  COUNT(*) FILTER (WHERE status = 'active') AS active,
  AVG(amount) FILTER (WHERE amount > 0) AS avg_positive
FROM accounts;

-- GROUPING SETS for multi-level rollups
SELECT region, product, SUM(revenue)
FROM sales
GROUP BY GROUPING SETS ((region, product), (region), ());

Padrões de migração

Scripts de migração ascendente/descendente

Toda migração deve ter uma contrapartida reversível. Nomeie os arquivos com um prefixo de data e hora para ordenação:

migrations/
├── 20260101_000001_create_users.up.sql
├── 20260101_000001_create_users.down.sql
├── 20260115_000002_add_users_email_index.up.sql
└── 20260115_000002_add_users_email_index.down.sql

Migrações sem tempo de inatividade (Expandir/Contrair)

Use o padrão expandir-contrair para evitar bloquear ou corromper o código em execução:

Expandir — adicione a nova coluna/tabela (com valor nulo permitido, com valor padrão)
Migrar dados — preencher em lotes; gravação dupla a partir do aplicativo
Transição — o aplicativo lê a partir da nova coluna; interrompe a gravação na antiga
Contrair — excluir a coluna antiga em uma migração subsequente

Estratégias de preenchimento de dados

-- Batch update to avoid long-running locks
UPDATE users SET email_normalized = LOWER(email)
WHERE id IN (SELECT id FROM users WHERE email_normalized IS NULL LIMIT 5000);
-- Repeat in a loop until 0 rows affected

Procedimentos de reversão

Sempre teste o down.sql no ambiente de teste antes de implantar up.sql para a produção
Mantenha a janela de reversão curta — se a etapa de contrato já tiver sido executada, a reversão exigirá uma nova migração para a frente
Para alterações irreversíveis (exclusão de colunas com dados), faça primeiro um backup lógico

Otimização de desempenho

Estratégias de indexação

Tipo de índice	Caso de uso	Exemplo
Árvore B (padrão)	Igualdade, intervalo, ORDER BY	`CREATE INDEX idx_users_email ON users(email);`
GIN	Pesquisa de texto completo, JSONB, matrizes	`CREATE INDEX idx_docs_body ON docs USING gin(to_tsvector('english', body));`
GiST	Geometria, tipos de intervalo, vizinho mais próximo	`CREATE INDEX idx_locations ON places USING gist(coords);`
Parcial	Subconjunto de linhas (redução de tamanho)	`CREATE INDEX idx_active ON users(email) WHERE active = true;`
Cobertura	Varreduras apenas no índice	`CREATE INDEX idx_cov ON orders(customer_id) INCLUDE (total, created_at);`

Leitura do plano EXPLAIN

EXPLAIN (ANALYZE, BUFFERS, FORMAT TEXT) SELECT ...;

Sinais importantes a serem observados:

Varredura sequencial em tabelas grandes — falta de índice
Nested Loop com estimativas elevadas de linhas — considere uma junção hash/merge ou adicione um índice
Leitura de buffers compartilhados muito superior ao número de acertos — o conjunto de trabalho excede a memória

Detecção de consultas N+1

Sintomas: o aplicativo emite uma consulta por linha (por exemplo, buscando registros relacionados em um loop).

Soluções:

Use JOIN ou subconsulta para buscar em uma única viagem
Carregamento antecipado do ORM (select_related / includes / with)
padrão DataLoader para resolvedores GraphQL

Pool de conexões

Ferramenta	Protocolo	Ideal para
PgBouncer	PostgreSQL	Agrupamento de transações/instruções, baixa sobrecarga
ProxySQL	MySQL	Roteamento de consultas, separação de leitura/gravação
Pool integrado (HikariCP, pool do SQLAlchemy)	Qualquer	Pooling no nível do aplicativo

Regra geral: defina o tamanho do pool como (2 * CPU cores) + disk spindles. Para SSDs na nuvem, comece com 2 * vCPUs e ajuste conforme necessário.

Réplicas de leitura e roteamento de consultas

Roteie todas as SELECT consultas para as réplicas; as gravações, para o primário
Leve em conta o atraso de replicação (normalmente <1 s para assíncrona, 0 para síncrona)
Use pg_last_wal_replay_lsn() para detectar o atraso antes de ler dados críticos

Matriz de decisão para múltiplos bancos de dados

Critérios	PostgreSQL	MySQL	SQLite	SQL Server
Ideal para	Consultas complexas, JSONB, extensões	Aplicativos web, cargas de trabalho com grande volume de leitura	Incorporado, desenvolvimento/teste, borda	Pilhas .NET corporativas
Suporte a JSON	Excelente (JSONB + GIN)	Bom (tipo JSON)	Mínimo	Bom (OPENJSON)
Replicação	Streaming, lógica	Replicação em grupo, cluster InnoDB	N/A	Always On AG
Licenciamento	Código aberto (Licença PostgreSQL)	Código aberto (GPL) / comercial	Domínio público	Comercial
Tamanho prático máximo	Vários TB	Vários TB	~1 TB (gravador único)	Vários TB

Quando escolher:

PostgreSQL — escolha padrão para novos projetos; melhor extensibilidade e conformidade com padrões
MySQL — ecossistema MySQL já existente; aplicativos web simples com grande volume de leituras
SQLite — aplicativos móveis, ferramentas de linha de comando, bancos de dados para testes unitários, IoT/edge
SQL Server — exigido pela política corporativa; integração profunda com .NET/Azure

Considerações sobre NoSQL

Banco de dados	Modelo	Quando usar
MongoDB	Documento	Flexibilidade de esquema, prototipagem rápida, gerenciamento de conteúdo
Redis	Chave-valor / cache	Armazenamento de sessões, limitação de taxa, tabelas de classificação, pub/sub
DynamoDB	Colunas largas	Aplicativos AWS sem servidor, latência de um dígito em milissegundos em qualquer escala

Use SQL como padrão. Recorra ao NoSQL somente quando o padrão de acesso se beneficiar claramente com isso.

Fragmentação e replicação

Particionamento horizontal x vertical

Particionamento vertical: divida colunas entre tabelas (por exemplo, separe colunas BLOB). Reduz a E/S para consultas restritas.
Particionamento horizontal (sharding): divide as linhas entre bancos de dados/servidores. Necessário quando um único nó não consegue armazenar o conjunto de dados ou lidar com a taxa de transferência.

Estratégias de fragmentação

Estratégia	Como funciona	Prós	Contras
Hash	`shard = hash(key) % N`	Distribuição uniforme	O resharding é caro
Intervalo	Fragmentação por data ou intervalo de IDs	Simples, ideal para séries temporais	Pontos de pico no shard mais recente
Geográfico	Fragmentação por região do usuário	Localidade dos dados, conformidade	Consultas entre regiões são complexas

Padrões de replicação

Padrão	Consistência	Latência	Caso de uso
Síncrono	Forte	Maior latência de gravação	Transações financeiras
Assíncrono	Eventual	Baixa latência de gravação	Aplicativos web com grande volume de leitura
Semissíncrono	Pelo menos uma réplica confirmada	Moderada	Equilíbrio entre segurança e velocidade

Referências cruzadas

sql-database-assistant — criação, otimização e depuração de consultas para o trabalho diário com SQL
database-schema-designer — modelagem ERD, análise de normalização e geração de esquemas
migration-architect — planejamento de migrações em grande escala entre mecanismos de banco de dados ou grandes reformulações de esquemas
senior-backend — padrões da camada de aplicação (pool de conexões, melhores práticas de ORM)
senior-devops — provisionamento de infraestrutura para clusters e réplicas de bancos de dados

Ver no GitHub

---
name: database-designer
description: Design database schemas, plan data migrations, optimize queries, and model data relationships using expert analysis and automated tools.
---

# Database Designer - POWERFUL Tier Skill

## Overview

A comprehensive database design skill that provides expert-level analysis, optimization, and migration capabilities for modern database systems. This skill combines theoretical principles with practical tools to help architects and developers create scalable, performant, and maintainable database schemas.

## Core Competencies

### Schema Design & Analysis
- **Normalization Analysis**: Automated detection of normalization levels (1NF through BCNF)
- **Denormalization Strategy**: Smart recommendations for performance optimization
- **Data Type Optimization**: Identification of inappropriate types and size issues
- **Constraint Analysis**: Missing foreign keys, unique constraints, and null checks
- **Naming Convention Validation**: Consistent table and column naming patterns
- **ERD Generation**: Automatic Mermaid diagram creation from DDL

### Index Optimization
- **Index Gap Analysis**: Identification of missing indexes on foreign keys and query patterns
- **Composite Index Strategy**: Optimal column ordering for multi-column indexes
- **Index Redundancy Detection**: Elimination of overlapping and unused indexes
- **Performance Impact Modeling**: Selectivity estimation and query cost analysis
- **Index Type Selection**: B-tree, hash, partial, covering, and specialized indexes

### Migration Management
- **Zero-Downtime Migrations**: Expand-contract pattern implementation
- **Schema Evolution**: Safe column additions, deletions, and type changes
- **Data Migration Scripts**: Automated data transformation and validation
- **Rollback Strategy**: Complete reversal capabilities with validation
- **Execution Planning**: Ordered migration steps with dependency resolution

## Tool Workflow (run these — do not analyze schemas by hand)

All paths relative to this skill folder; sample inputs in `assets/`.

### 1. Analyze the schema

```bash
python3 schema_analyzer.py --input schema.sql --generate-erd --output-format json -o analysis.json
```

Accepts SQL DDL or JSON schema (`assets/sample_schema.sql` / `sample_schema.json`). Output includes normalization findings, missing constraints, naming issues, and a Mermaid ERD — show the ERD to the user and fix flagged issues before optimizing.

### 2. Optimize indexes against real query patterns

```bash
python3 index_optimizer.py --schema assets/sample_schema.json --queries assets/sample_query_patterns.json --analyze-existing --format json -o indexes.json
```

Write the user's hot queries into a query-patterns JSON first (copy `assets/sample_query_patterns.json`). Output is a priority-ordered list of CREATE INDEX recommendations plus redundant-index removals.

### 3. Generate the migration

```bash
python3 migration_generator.py --current current_schema.json --target target_schema.json --zero-downtime --format sql -o migration.sql
```

`--zero-downtime` emits an expand-contract plan; `--validate-only` checks feasibility without generating SQL.

### 4. Verification loop

Re-run step 1 on the *target* schema and assert the issues found in the first pass are gone; run `migration_generator.py --validate-only` before handing over the migration.

## Database Design Principles
→ See references/database-design-reference.md for details

## Best Practices

### Schema Design
1. **Use meaningful names**: Clear, consistent naming conventions
2. **Choose appropriate data types**: Right-sized columns for storage efficiency
3. **Define proper constraints**: Foreign keys, check constraints, unique indexes
4. **Consider future growth**: Plan for scale from the beginning
5. **Document relationships**: Clear foreign key relationships and business rules

### Performance Optimization
1. **Index strategically**: Cover common query patterns without over-indexing
2. **Monitor query performance**: Regular analysis of slow queries
3. **Partition large tables**: Improve query performance and maintenance
4. **Use appropriate isolation levels**: Balance consistency with performance
5. **Implement connection pooling**: Efficient resource utilization

### Security Considerations
1. **Principle of least privilege**: Grant minimal necessary permissions
2. **Encrypt sensitive data**: At rest and in transit
3. **Audit access patterns**: Monitor and log database access
4. **Validate inputs**: Prevent SQL injection attacks
5. **Regular security updates**: Keep database software current

## Query Generation Patterns

### SELECT with JOINs

```sql
-- INNER JOIN: only matching rows
SELECT o.id, c.name, o.total
FROM orders o
INNER JOIN customers c ON c.id = o.customer_id;

-- LEFT JOIN: all left rows, NULLs for non-matches
SELECT c.name, COUNT(o.id) AS order_count
FROM customers c
LEFT JOIN orders o ON o.customer_id = c.id
GROUP BY c.name;

-- Self-join: hierarchical data (employees/managers)
SELECT e.name AS employee, m.name AS manager
FROM employees e
LEFT JOIN employees m ON m.id = e.manager_id;
```

### Common Table Expressions (CTEs)

```sql
-- Recursive CTE for org chart
WITH RECURSIVE org AS (
  SELECT id, name, manager_id, 1 AS depth
  FROM employees WHERE manager_id IS NULL
  UNION ALL
  SELECT e.id, e.name, e.manager_id, o.depth + 1
  FROM employees e INNER JOIN org o ON o.id = e.manager_id
)
SELECT * FROM org ORDER BY depth, name;
```

### Window Functions

```sql
-- ROW_NUMBER for pagination / dedup
SELECT *, ROW_NUMBER() OVER (PARTITION BY customer_id ORDER BY created_at DESC) AS rn
FROM orders;

-- RANK with gaps, DENSE_RANK without gaps
SELECT name, score, RANK() OVER (ORDER BY score DESC) AS rank FROM leaderboard;

-- LAG/LEAD for comparing adjacent rows
SELECT date, revenue,
  revenue - LAG(revenue) OVER (ORDER BY date) AS daily_change
FROM daily_sales;
```

### Aggregation Patterns

```sql
-- FILTER clause (PostgreSQL) for conditional aggregation
SELECT
  COUNT(*) AS total,
  COUNT(*) FILTER (WHERE status = 'active') AS active,
  AVG(amount) FILTER (WHERE amount > 0) AS avg_positive
FROM accounts;

-- GROUPING SETS for multi-level rollups
SELECT region, product, SUM(revenue)
FROM sales
GROUP BY GROUPING SETS ((region, product), (region), ());
```

---

## Migration Patterns

### Up/Down Migration Scripts

Every migration must have a reversible counterpart. Name files with a timestamp prefix for ordering:

```
migrations/
├── 20260101_000001_create_users.up.sql
├── 20260101_000001_create_users.down.sql
├── 20260115_000002_add_users_email_index.up.sql
└── 20260115_000002_add_users_email_index.down.sql
```

### Zero-Downtime Migrations (Expand/Contract)

Use the expand-contract pattern to avoid locking or breaking running code:

1. **Expand** — add the new column/table (nullable, with default)
2. **Migrate data** — backfill in batches; dual-write from application
3. **Transition** — application reads from new column; stop writing to old
4. **Contract** — drop old column in a follow-up migration

### Data Backfill Strategies

```sql
-- Batch update to avoid long-running locks
UPDATE users SET email_normalized = LOWER(email)
WHERE id IN (SELECT id FROM users WHERE email_normalized IS NULL LIMIT 5000);
-- Repeat in a loop until 0 rows affected
```

### Rollback Procedures

- Always test the `down.sql` in staging before deploying `up.sql` to production
- Keep rollback window short — if the contract step has run, rollback requires a new forward migration
- For irreversible changes (dropping columns with data), take a logical backup first

---

## Performance Optimization

### Indexing Strategies

| Index Type | Use Case | Example |
|------------|----------|---------|
| **B-tree** (default) | Equality, range, ORDER BY | `CREATE INDEX idx_users_email ON users(email);` |
| **GIN** | Full-text search, JSONB, arrays | `CREATE INDEX idx_docs_body ON docs USING gin(to_tsvector('english', body));` |
| **GiST** | Geometry, range types, nearest-neighbor | `CREATE INDEX idx_locations ON places USING gist(coords);` |
| **Partial** | Subset of rows (reduce size) | `CREATE INDEX idx_active ON users(email) WHERE active = true;` |
| **Covering** | Index-only scans | `CREATE INDEX idx_cov ON orders(customer_id) INCLUDE (total, created_at);` |

### EXPLAIN Plan Reading

```sql
EXPLAIN (ANALYZE, BUFFERS, FORMAT TEXT) SELECT ...;
```

Key signals to watch:
- **Seq Scan** on large tables — missing index
- **Nested Loop** with high row estimates — consider hash/merge join or add index
- **Buffers shared read** much higher than **hit** — working set exceeds memory

### N+1 Query Detection

Symptoms: application issues one query per row (e.g., fetching related records in a loop).

Fixes:
- Use `JOIN` or subquery to fetch in one round-trip
- ORM eager loading (`select_related` / `includes` / `with`)
- DataLoader pattern for GraphQL resolvers

### Connection Pooling

| Tool | Protocol | Best For |
|------|----------|----------|
| **PgBouncer** | PostgreSQL | Transaction/statement pooling, low overhead |
| **ProxySQL** | MySQL | Query routing, read/write splitting |
| **Built-in pool** (HikariCP, SQLAlchemy pool) | Any | Application-level pooling |

**Rule of thumb:** Set pool size to `(2 * CPU cores) + disk spindles`. For cloud SSDs, start with `2 * vCPUs` and tune.

### Read Replicas and Query Routing

- Route all `SELECT` queries to replicas; writes to primary
- Account for replication lag (typically <1s for async, 0 for sync)
- Use `pg_last_wal_replay_lsn()` to detect lag before reading critical data

---

## Multi-Database Decision Matrix

| Criteria | PostgreSQL | MySQL | SQLite | SQL Server |
|----------|-----------|-------|--------|------------|
| **Best for** | Complex queries, JSONB, extensions | Web apps, read-heavy workloads | Embedded, dev/test, edge | Enterprise .NET stacks |
| **JSON support** | Excellent (JSONB + GIN) | Good (JSON type) | Minimal | Good (OPENJSON) |
| **Replication** | Streaming, logical | Group replication, InnoDB cluster | N/A | Always On AG |
| **Licensing** | Open source (PostgreSQL License) | Open source (GPL) / commercial | Public domain | Commercial |
| **Max practical size** | Multi-TB | Multi-TB | ~1 TB (single-writer) | Multi-TB |

**When to choose:**
- **PostgreSQL** — default choice for new projects; best extensibility and standards compliance
- **MySQL** — existing MySQL ecosystem; simple read-heavy web applications
- **SQLite** — mobile apps, CLI tools, unit test databases, IoT/edge
- **SQL Server** — mandated by enterprise policy; deep .NET/Azure integration

### NoSQL Considerations

| Database | Model | Use When |
|----------|-------|----------|
| **MongoDB** | Document | Schema flexibility, rapid prototyping, content management |
| **Redis** | Key-value / cache | Session store, rate limiting, leaderboards, pub/sub |
| **DynamoDB** | Wide-column | Serverless AWS apps, single-digit-ms latency at any scale |

> Use SQL as default. Reach for NoSQL only when the access pattern clearly benefits from it.

---

## Sharding & Replication

### Horizontal vs Vertical Partitioning

- **Vertical partitioning**: Split columns across tables (e.g., separate BLOB columns). Reduces I/O for narrow queries.
- **Horizontal partitioning (sharding)**: Split rows across databases/servers. Required when a single node cannot hold the dataset or handle the throughput.

### Sharding Strategies

| Strategy | How It Works | Pros | Cons |
|----------|-------------|------|------|
| **Hash** | `shard = hash(key) % N` | Even distribution | Resharding is expensive |
| **Range** | Shard by date or ID range | Simple, good for time-series | Hot spots on latest shard |
| **Geographic** | Shard by user region | Data locality, compliance | Cross-region queries are hard |

### Replication Patterns

| Pattern | Consistency | Latency | Use Case |
|---------|------------|---------|----------|
| **Synchronous** | Strong | Higher write latency | Financial transactions |
| **Asynchronous** | Eventual | Low write latency | Read-heavy web apps |
| **Semi-synchronous** | At-least-one replica confirmed | Moderate | Balance of safety and speed |

---

## Cross-References

- **sql-database-assistant** — query writing, optimization, and debugging for day-to-day SQL work
- **database-schema-designer** — ERD modeling, normalization analysis, and schema generation
- **migration-architect** — large-scale migration planning across database engines or major schema overhauls
- **senior-backend** — application-layer patterns (connection pooling, ORM best practices)
- **senior-devops** — infrastructure provisioning for database clusters and replicas

Todos os arquivos

0 arquivos

Instalar database-designer

Baixe e descompacte os arquivos das habilidades no diretório .claude/skills/.

Baixar ZIP

Clone o repositório e copie os arquivos da habilidade para o seu projeto.

git clone https://github.com/alirezarezvani/claude-skills/tree/main/engineering/skills/database-designer # Copy SKILL.md to your .claude/skills/ directory

Copiar

Configuração rápida: Copie a pasta da habilidade para .claude/skills/ O Claude detectará e utilizará a habilidade automaticamente

Repositório alirezarezvani/claude-skills

Habilidades relacionadas

microservices-patterns

Tempo atualizado 29 de Junho de 2026

jpa-patterns

Tempo atualizado 30 de Junho de 2026

fabric-lakehouse

Tempo atualizado 30 de Junho de 2026

prisma-expert

Tempo atualizado 29 de Junho de 2026