postgresql-table-design
Crie esquemas PostgreSQL com orientação especializada
O design de esquemas PostgreSQL requer conhecimento de tipos de dados, estratégias de indexação, restrições e padrões de desempenho. Esta skill oferece orientação abrangente sobre melhores práticas específicas do PostgreSQL, recursos avançados e armadilhas comuns para ajudá-lo a construir esquemas de banco de dados eficientes e sustentáveis.
Baixar o ZIP da skill
Upload no Claude
Vá em Configurações → Capacidades → Skills → Upload skill
Ative e comece a usar
Testar
A utilizar "postgresql-table-design". Como devo armazenar valores monetários no PostgreSQL?
Resultado esperado:
Use NUMERIC(p,s) para valores monetários, nunca tipos float. Por exemplo: amount NUMERIC(10,2) para moeda com duas casas decimais. Isso fornece aritmética decimal exata sem problemas de precisão de ponto flutuante. Evite o tipo money desatualizado.
A utilizar "postgresql-table-design". Qual é a diferença entre BIGINT GENERATED ALWAYS AS IDENTITY e UUID para chaves primárias?
Resultado esperado:
- BIGINT GENERATED ALWAYS AS IDENTITY: IDs inteiros sequenciais. Preferido para a maioria dos casos de uso. Benefícios: armazenamento menor, indexação mais rápida, melhor localidade. Use quando a exclusividade global entre sistemas não é necessária.
- UUID: Identificadores globalmente únicos. Use quando: mesclando dados de múltiplos bancos de dados, federando sistemas, ou quando precisar de IDs opacos não sequenciais. Gere com uuidv7() no PostgreSQL 18+ ou gen_random_uuid() em versões mais antigas.
A utilizar "postgresql-table-design". Devo adicionar índices em colunas de chave estrangeira?
Resultado esperado:
Sim, sempre adicione índices explícitos em colunas de chave estrangeira. O PostgreSQL não cria índices automáticos em colunas FK, ao contrário de alguns bancos de dados. Isso acelera joins e evita problemas de bloqueio durante exclusões ou atualizações na tabela pai. Exemplo: CREATE INDEX ON orders (user_id) para chave estrangeira user_id.
Auditoria de Segurança
SeguroThis 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.
Pontuação de qualidade
O Que Você Pode Construir
Criar um novo esquema de banco de dados
Obtenha orientação sobre estrutura de tabelas, tipos de dados, restrições e estratégias de indexação ao criar um novo banco de dados PostgreSQL para uma aplicação.
Otimizar o desempenho de esquemas existentes
Aprenda sobre estratégias de indexação, opções de particionamento e padrões de desempenho para melhorar o desempenho de consultas e reduzir a expansão do banco de dados.
Revisar decisões de design de esquema
Valide escolhas de tipos de dados, uso de restrições e decisões de normalização de acordo com as melhores práticas do PostgreSQL antes da implementação.
Tente Estes Prompts
Preciso criar uma tabela de usuários com email, nome e timestamps. Qual é o esquema PostgreSQL recomendado?
Estou armazenando preços de produtos, endereços IP e preferências de usuário. Quais tipos de dados PostgreSQL devo usar?
Minha tabela de pedidos tem consultas filtrando por user_id, status e created_at. Quais índices devo criar?
Preciso armazenar milhões de leituras de sensores por dia com consultas filtrando por dispositivo e intervalo de tempo. Como devo projetar o esquema e o particionamento?
Melhores Práticas
- Comece com esquemas normalizados até a terceira forma normal e só desnormalize quando tiver medido problemas de desempenho com consultas específicas de alto valor
- Use TIMESTAMPTZ para todas as colunas de timestamp, TEXT para strings, NUMERIC para dinheiro e BIGINT GENERATED ALWAYS AS IDENTITY para chaves primárias, a menos que precise de UUIDs
- Crie índices para colunas usadas em cláusulas WHERE, condições JOIN e cláusulas ORDER BY, e sempre adicione índices explícitos em colunas de chave estrangeira
Evitar
- Não use tipos de dados VARCHAR(n) ou CHAR(n); use TEXT com restrições CHECK para limites de comprimento, se necessário
- Não use TIMESTAMP sem fuso horário, o tipo money ou SERIAL; use TIMESTAMPTZ, NUMERIC e GENERATED ALWAYS AS IDENTITY
- Não desnormalize dados prematuramente antes de medir problemas de desempenho reais; a desnormalização prematura cria carga de manutenção sem benefícios comprovados