hicucu/rdb-skill

Banco de Dados Relacional (Independente de Mecanismo)

Visão Geral

Práticas recomendadas neutras em relação ao mecanismo para bancos de dados relacionais. Princípios e padrões são escritos uma vez; apenas os pontos onde os dialetos SQL divergem (MSSQL vs MySQL/MariaDB) são sinalizados inline ou coletados na folha de dicas de dialetos. Otimize para correção e a menor mudança apoiada por evidências medidas.

Quando Usar

• Projetando ou revisando um esquema (tabelas, chaves, normalização, tipos de dados).
• Adicionando ou corrigindo índices; diagnosticando consultas lentas ou varreduras completas de tabelas.
• Lendo um plano de execução para encontrar o gargalo.
• Escolhendo ou solucionando problemas de isolamento de transação, bloqueio ou deadlocks.
• Paginando grandes conjuntos de resultados; eliminando acesso N+1.
• Planejando uma migração de esquema segura para produção.

Não para: mergulhos profundos internos do mecanismo (internos do mecanismo de armazenamento como buffer pool InnoDB, recursos específicos do fornecedor, construções exclusivas do T-SQL, topologia de replicação/ fragmentação). Use a documentação do próprio mecanismo ou uma skill dedicada a um único mecanismo.

Fluxo de Trabalho

1. Estabeleça o contexto primeiro. Qual mecanismo + versão principal? Mix de leitura/gravação, volume de linhas, meta de latência, OLTP vs análise. As recomendações mudam com esses fatores.
2. Leia apenas a referência relevante vinculada em cada seção abaixo.
3. Proponha a menor mudança que resolva o problema, com compensações.
4. Valide com evidências — capture um plano de execução e métricas de linhas/tempo antes e depois (consulte references/execution-plans.md), não regras práticas.
5. Para produção, inclua um plano de rollback e verificação pós-implantação.

Design de Esquema

• Modele relacionamentos explicitamente; comece normalizado (3FN/BCNF) e desnormalize apenas com uma razão medida. Toda tabela precisa de uma chave primária estável.
• Escolha o tipo de dados correto mais estreito; restrinja estados inválidos no nível do esquema (NOT NULL, UNIQUE, CHECK, FK) em vez de apenas no código da aplicação.

Referências: normalização · chaves-e-restrições · tipos-de-dados

Indexação

• Indexe colunas usadas em WHERE, JOIN e ORDER BY — por seletividade, não por adivinhação. Ordem de índice composto: colunas de igualdade primeiro, depois intervalo/ordenação (regra de prefixo mais à esquerda). Um predicado de intervalo interrompe o uso do índice para colunas posteriores.
• Índices de cobertura evitam buscas na tabela. Audite e remova índices não utilizados/duplicados; todo índice sobrecarrega as gravações.

Referências: indexação · índices-compostos

Otimização de Consultas

• Mantenha os predicados SARGáveis — sem funções/casts implícitos em colunas indexadas em WHERE. Selecione apenas as colunas necessárias. Prefira EXISTS sobre IN (subconsulta), UNION ALL sobre UNION quando a desduplicação não for necessária, e lote grandes gravações.
• Use paginação por conjunto de chaves (cursor) em vez de OFFSET grande. Elimine N+1 agrupando ou juntando.

Referências: otimização-de-consultas · planos-de-execução · paginação

Transações e Bloqueio

• Mantenha as transações curtas; faça E/S e trabalho lento fora delas. Acesse linhas em uma ordem consistente para evitar deadlocks; espere deadlocks e tente novamente com backoff.
• Conheça o nível de isolamento padrão do seu mecanismo (é diferente) e as anomalias que cada nível permite. Use leituras de bloqueio (FOR UPDATE) deliberadamente, não por hábito.

Referências: transações-e-isolamento · bloqueio-e-deadlocks

Migrações e DDL

• Faça alterações de esquema de forma aditiva e compatível com versões anteriores: expanda → preencha → contraia. DDL grande/com bloqueio precisa de uma estratégia online e um caminho de rollback.

Referência: migrações-e-ddl

Diferenças de Dialeto do Mecanismo

Auto-incremento, citação de identificadores, paginação, upsert, funções de string, hora atual, EXPLAIN e padrões de isolamento divergem entre os mecanismos. Confirme a sintaxe para o mecanismo de destino antes de escrever SQL portável.

Referência: folha-de-dicas-de-dialeto-do-mecanismo

Salvaguardas

• Prefira evidências medidas (planos de execução, métricas) em vez de regras genéricas.
• Declare o mecanismo e versão principal quando o comportamento depender dele.
• Obtenha aprovação humana explícita antes de operações destrutivas (DROP/DELETE/TRUNCATE ou qualquer migração não reversível). Sempre confirme que existe um backup primeiro.