Revisão de Código SQL

Realize uma revisão completa do código SQL de ${selection} (ou do projeto inteiro, se nenhuma seleção for feita) com foco em segurança, desempenho, manutenibilidade e melhores práticas de banco de dados.

🔒 Análise de Segurança

Prevenção de Injeção de SQL

-- ❌ CRITICAL: SQL Injection vulnerability
query = "SELECT * FROM users WHERE id = " + userInput;
query = f"DELETE FROM orders WHERE user_id = {user_id}";

-- ✅ SECURE: Parameterized queries
-- PostgreSQL/MySQL
PREPARE stmt FROM 'SELECT * FROM users WHERE id = ?';
EXECUTE stmt USING @user_id;

-- SQL Server
EXEC sp_executesql N'SELECT * FROM users WHERE id = @id', N'@id INT', @id = @user_id;

Controle de Acesso e Permissões

• Princípio do Menor Privilégio: Conceda as permissões mínimas necessárias
• Acesso Baseado em Papéis: Use papéis de banco de dados em vez de permissões diretas de usuário
• Segurança de Esquema: Propriedade de esquema e controles de acesso adequados
• Segurança de Funções/Procedimentos: Revise os direitos DEFINER vs INVOKER

Proteção de Dados

• Exposição de Dados Sensíveis: Evite SELECT * em tabelas com colunas sensíveis
• Registro de Auditoria: Garanta que operações sensíveis sejam registradas
• Mascaramento de Dados: Use visualizações ou funções para mascarar dados sensíveis
• Criptografia: Verifique o armazenamento criptografado para dados sensíveis

⚡ Otimização de Desempenho

Análise da Estrutura da Consulta

-- ❌ BAD: Inefficient query patterns
SELECT DISTINCT u.* 
FROM users u, orders o, products p
WHERE u.id = o.user_id 
AND o.product_id = p.id
AND YEAR(o.order_date) = 2024;

-- ✅ GOOD: Optimized structure
SELECT u.id, u.name, u.email
FROM users u
INNER JOIN orders o ON u.id = o.user_id
WHERE o.order_date >= '2024-01-01' 
AND o.order_date < '2025-01-01';

Revisão da Estratégia de Índices

• Índices Ausentes: Identifique colunas que precisam de indexação
• Excesso de Índices: Encontre índices não utilizados ou redundantes
• Índices Compostos: Índices de múltiplas colunas para consultas complexas
• Manutenção de Índices: Verifique índices fragmentados ou desatualizados

Otimização de Joins

• Tipos de Join: Verifique os tipos de join apropriados (INNER vs LEFT vs EXISTS)
• Ordem de Join: Otimize para conjuntos de resultados menores primeiro
• Produtos Cartesianos: Identifique e corrija condições de join ausentes
• Subconsulta vs JOIN: Escolha a abordagem mais eficiente

Funções de Agregação e Janela

-- ❌ BAD: Inefficient aggregation
SELECT user_id, 
       (SELECT COUNT(*) FROM orders o2 WHERE o2.user_id = o1.user_id) as order_count
FROM orders o1
GROUP BY user_id;

-- ✅ GOOD: Efficient aggregation
SELECT user_id, COUNT(*) as order_count
FROM orders
GROUP BY user_id;

🛠️ Qualidade de Código e Manutenibilidade

Estilo e Formatação SQL

-- ❌ BAD: Poor formatting and style
select u.id,u.name,o.total from users u left join orders o on u.id=o.user_id where u.status='active' and o.order_date>='2024-01-01';

-- ✅ GOOD: Clean, readable formatting
SELECT u.id,
       u.name,
       o.total
FROM users u
LEFT JOIN orders o ON u.id = o.user_id
WHERE u.status = 'active'
  AND o.order_date >= '2024-01-01';

Convenções de Nomenclatura

• Nomenclatura Consistente: Tabelas, colunas, restrições seguem padrões consistentes
• Nomes Descritivos: Nomes claros e significativos para objetos de banco de dados
• Palavras Reservadas: Evite usar palavras reservadas do banco de dados como identificadores
• Sensibilidade a Maiúsculas/Minúsculas: Uso consistente de maiúsculas/minúsculas em todo o esquema

Revisão do Design do Esquema

• Normalização: Nível de normalização apropriado (evite excesso/falta de normalização)
• Tipos de Dados: Escolhas ótimas de tipos de dados para armazenamento e desempenho
• Restrições: Uso adequado de PRIMARY KEY, FOREIGN KEY, CHECK, NOT NULL
• Valores Padrão: Valores padrão apropriados para colunas

🗄️ Melhores Práticas Específicas do Banco de Dados

PostgreSQL

-- Use JSONB for JSON data
CREATE TABLE events (
    id SERIAL PRIMARY KEY,
    data JSONB NOT NULL,
    created_at TIMESTAMPTZ DEFAULT NOW()
);

-- GIN index for JSONB queries
CREATE INDEX idx_events_data ON events USING gin(data);

-- Array types for multi-value columns
CREATE TABLE tags (
    post_id INT,
    tag_names TEXT[]
);

MySQL

-- Use appropriate storage engines
CREATE TABLE sessions (
    id VARCHAR(128) PRIMARY KEY,
    data TEXT,
    expires TIMESTAMP
) ENGINE=InnoDB;

-- Optimize for InnoDB
ALTER TABLE large_table 
ADD INDEX idx_covering (status, created_at, id);

SQL Server

-- Use tipos de dados apropriados
CREATE TABLE produtos (
    id BIGINT IDENTITY(1,1) PRIMARY KEY,
    nome NVARCHAR(255) NOT NULL,
    preco DECIMAL(10,2) NOT NULL,

…