 |
| Bellacosa Mainframe e o sql sem misterios |
☕ Um Café no Bellacosa Mainframe
SQL sem Mistérios — O Caminho do Programador COBOL Padawan para Pensar Como um Analista Sênior
Da Tela Verde do IBM Z à Ponte da USS Enterprise: por que escrever SQL é apenas o começo da missão
"A lógica é o princípio da sabedoria, não o seu fim."
— Adaptado de Spock
Introdução — O dia em que descobri que SQL não era o verdadeiro problema
Existe um momento na carreira de praticamente todo programador COBOL em que acontece algo curioso.
Você termina seu primeiro programa COBOL com Embedded SQL.
Compila.
Faz o BIND.
Executa o JCL.
O programa termina RC=0000.
Os dados aparecem na tela.
Você sorri.
"Parece que deu certo."
Dias depois...
O usuário telefona.
— "Os números estão errados."
Você verifica novamente.
O programa funciona.
O SQL executa.
Nenhum SQLCODE negativo.
Nenhum ABEND.
Mesmo assim...
Os números continuam errados.
Foi exatamente nesse momento que milhares de desenvolvedores descobriram uma verdade que nenhum livro de SQL ensina:
Escrever SQL é fácil. Produzir informação confiável é a verdadeira profissão.
É justamente essa diferença que separa um analista iniciante de um analista experiente.
No universo do IBM Z, essa diferença pode representar:
milhões de registros processados corretamente;
horas de CPU economizadas;
auditorias aprovadas;
noites tranquilas para o operador do JES2.
Hoje embarcaremos na USS Enterprise para entender por que dois profissionais podem escrever praticamente o mesmo SQL e, ainda assim, entregar resultados completamente diferentes.
Prepare seu tricorder.
O Capitão autorizou nossa missão.
Capítulo 1 — A USS Enterprise e o IBM Z
Imagine a Enterprise.
Todos conhecem o computador da nave.
Mas quem realmente toma decisões?
Não é o computador.
É a tripulação.
O computador apenas executa ordens.
O Db2 faz exatamente isso.
Ele não sabe o significado de:
cliente
pagamento
imposto
comissão
salário
Ele apenas processa relacionamentos matemáticos.
Quem entende o negócio é você.
E aí aparece a primeira lição do Dr. Spock.
"O computador não produz inteligência.
Apenas executa lógica."
Capítulo 2 — O maior erro do Padawan
O iniciante abre o SPUFI ou o Data Studio.
Digita:
SELECT *
FROM CLIENTES;
Executa.
Olha.
Executa novamente.
Adiciona uma coluna.
Executa outra vez.
Coloca um JOIN.
Executa novamente.
Esse comportamento possui um nome.
Programação por tentativa e erro.
Funciona?
Às vezes.
Escala?
Nunca.
Como o veterano trabalha
Antes de abrir qualquer editor, ele responde perguntas.
O que o usuário deseja?
Qual decisão será tomada com esse relatório?
Quem utilizará esses dados?
Qual é a definição oficial desse indicador?
Qual a granularidade?
Cliente?
Pedido?
Produto?
Contrato?
Conta bancária?
Só depois disso ele escreve SQL.
O código nasce praticamente pronto.
Capítulo 3 — A Granularidade: o segredo escondido
Poucos iniciantes aprendem isso.
Na verdade, talvez seja um dos conceitos mais importantes do Data Warehouse moderno.
Imagine estas tabelas:
CLIENTES
Cliente
Nome
Cidade
PEDIDOS
Pedido
Cliente
Valor
ITENS
Pedido
Produto
Quantidade
Pergunta simples:
Qual o faturamento por cliente?
Muitos fazem:
CLIENTES
↓
PEDIDOS
↓
ITENS
↓
SUM()
Resultado?
Dobrou.
Triplicou.
Explodiu.
Por quê?
Porque cada pedido aparece várias vezes.
Cada item multiplica o valor.
Esse fenômeno recebe um nome:
Cardinality Explosion
No Db2 ele custa CPU.
Na empresa custa credibilidade.
Curiosidade Bellacosa ☕
A maioria dos erros financeiros em SQL não acontece porque alguém escreveu uma função errada.
Acontece porque alguém esqueceu a granularidade.
Capítulo 4 — O mito do DISTINCT
Todo mundo já viu isso.
SELECT DISTINCT
Magicamente...
Os números diminuem.
Parece resolvido.
Na verdade...
Você acabou de esconder um problema.
DISTINCT remove linhas iguais.
Mas não explica por que elas ficaram iguais.
É como desligar o alarme de incêndio sem apagar o fogo.
Como Spock resolveria
Primeiro ele perguntaria:
Existe chave primária?
Existe chave composta?
Existe relacionamento 1:N?
Existe histórico?
Existe duplicidade legítima?
Depois faria o JOIN.
Capítulo 5 — O verdadeiro significado do JOIN
JOIN não significa unir tabelas.
JOIN significa combinar entidades diferentes preservando significado.
Um JOIN correto exige conhecer:
regras de negócio;
integridade referencial;
cardinalidade;
qualidade dos dados.
No mainframe isso é ainda mais importante porque muitas aplicações nasceram décadas antes da existência das chaves estrangeiras automáticas.
Você precisa conhecê-las.
Capítulo 6 — SELECT * custa dinheiro
O iniciante pensa:
"Mais fácil pegar tudo."
O Db2 pensa diferente.
Cada coluna significa:
mais páginas;
mais buffer pool;
mais cache;
mais leitura;
mais CPU.
Imagine uma tabela com 300 colunas.
Seu relatório usa apenas cinco.
SELECT *
lê as 300.
Num IBM Z isso significa MIPS.
MIPS significam dinheiro.
Regra de ouro
Selecione somente o que será utilizado.
Nem uma coluna a mais.
Capítulo 7 — A arte de confiar nos dados
O iniciante olha dez linhas.
"Parece certo."
Entrega.
O analista experiente nunca acredita na primeira execução.
Ele faz auditorias.
Checklist clássico
COUNT(*)
COUNT(coluna)
COUNT(DISTINCT)
MIN()
MAX()
AVG()
NULL
Duplicados
Valores negativos
Faixas inválidas
Datas futuras
Datas impossíveis
Esse ritual pode parecer exagerado.
Até o dia em que salva sua carreira.
Easter Egg Star Trek
Na Enterprise existe redundância em praticamente tudo.
Motores.
Computadores.
Sensores.
Por quê?
Porque confiar em um único indicador é perigoso.
O mesmo vale para SQL.
Nunca valide apenas uma métrica.
Capítulo 8 — NULL: o inimigo invisível
NULL é talvez o conceito mais incompreendido do SQL.
NULL não significa:
zero
vazio
espaço
falso
NULL significa:
valor desconhecido.
Veja:
WHERE SALARIO > 5000
Quem possui NULL?
Some.
Sem aviso.
Sem erro.
Sem SQLCODE.
Quantos relatórios já ficaram errados por causa disso?
Milhares.
Capítulo 9 — Performance não começa depois
Muitos pensam:
Primeiro faço funcionar.
Depois otimizo.
O veterano pensa diferente.
Ele escreve pensando no otimizador.
O EXPLAIN é seu tricorder
No Star Trek, ninguém entra em um planeta desconhecido sem usar o tricorder.
No Db2, ninguém deveria executar uma consulta crítica sem analisar o EXPLAIN.
Ele mostra:
índice usado;
tipo de JOIN;
SORT;
acesso sequencial;
custo estimado;
filtro aplicado.
É literalmente o mapa da missão.
Capítulo 10 — O índice é um elevador
Imagine um prédio.
Você precisa ir ao andar 90.
Sem elevador.
Escadas.
Isso é um Table Space Scan.
Agora imagine um elevador.
Isso é um índice.
Agora imagine alguém fechando a porta do elevador.
Quem faz isso?
Funções sobre colunas indexadas.
Exemplo:
WHERE YEAR(DATA)=2026
Melhor:
WHERE DATA BETWEEN ...
Agora o elevador funciona novamente.
Capítulo 11 — Window Functions
Antigamente fazíamos:
JOIN
JOIN
JOIN
Subconsulta
Mais JOIN
Hoje basta:
ROW_NUMBER()
RANK()
LAG()
LEAD()
SUM() OVER()
Essas funções diminuem:
CPU
complexidade
manutenção
e deixam o código muito mais elegante.
Capítulo 12 — CTEs: capítulos de uma história
O iniciante escreve um SQL de 700 linhas.
Sem espaços.
Sem comentários.
Boa sorte.
O veterano usa CTEs.
ClientesAtivos
↓
PedidosRecentes
↓
PedidosValidados
↓
ResumoFinanceiro
↓
Resultado
Cada bloco conta uma parte da história.
O SQL vira documentação.
Capítulo 13 — Comentários inteligentes
Comentário ruim:
-- soma valores
Comentário útil:
-- Clientes ativos são aqueles
-- que efetuaram pelo menos
-- uma compra nos últimos
-- 180 dias conforme definição
-- da área financeira.
Explique o motivo.
Nunca o óbvio.
Capítulo 14 — O poder da reutilização
Uma consulta salva na área de trabalho morre junto com o computador.
Uma View.
Uma Stored Procedure.
Uma biblioteca Git.
Sobrevivem anos.
O conhecimento coletivo vale muito mais que scripts isolados.
Capítulo 15 — O que o COBOL ensina sobre SQL
Curiosamente, programadores COBOL costumam desenvolver uma vantagem natural.
Eles aprendem cedo conceitos como:
precisão;
processamento determinístico;
validação;
tratamento de erros;
responsabilidade sobre os dados.
Esses princípios se encaixam perfeitamente em SQL.
O verdadeiro desafio é abandonar a mentalidade de "fazer funcionar" e adotar a mentalidade de "garantir que está correto".
Capítulo 16 — O Fluxo Mental de um Analista Sênior
Antes de escrever qualquer linha de SQL, um profissional experiente costuma seguir um roteiro semelhante:
Compreender a pergunta de negócio.
Identificar a fonte oficial dos dados.
Definir a granularidade do resultado.
Verificar chaves primárias, candidatas e relacionamentos.
Planejar filtros para reduzir o volume de dados o mais cedo possível.
Escolher apenas as colunas necessárias.
Esboçar CTEs que representem cada etapa da lógica.
Executar consultas de auditoria (
COUNT,COUNT(DISTINCT),MIN,MAX, análise deNULL).Avaliar o plano de execução com
EXPLAIN.Comparar o resultado com uma fonte confiável.
Documentar as regras de negócio.
Versionar a solução para que toda a equipe possa reutilizá-la.
Perceba que escrever o SELECT é apenas uma pequena parte desse processo.
Curiosidades
O primeiro SQL raramente é o melhor
Analistas experientes reescrevem consultas várias vezes antes de entregá-las. Não porque o SQL esteja errado, mas porque sempre existe uma forma mais clara, mais eficiente ou mais fácil de manter.
O melhor SQL é o que outro profissional entende
Uma consulta extremamente inteligente, mas impossível de ler, costuma gerar mais problemas do que benefícios. Clareza é uma característica de engenharia.
O DBA e o desenvolvedor não são adversários
Em muitas equipes, existe a falsa ideia de que o DBA apenas "reclama" das consultas lentas. Na prática, o DBA enxerga o comportamento do banco como um todo e pode identificar oportunidades que passam despercebidas durante o desenvolvimento.
Bellacosa Mainframe — Dicas do Capitão
✅ Entenda o problema antes de abrir o editor.
✅ Nunca use SELECT * em produção sem um motivo claro.
✅ Conheça a granularidade dos dados antes de fazer JOIN.
✅ Desconfie de qualquer DISTINCT que "resolve" um problema.
✅ Sempre audite NULL, duplicidades e totais.
✅ Aprenda a interpretar EXPLAIN com a mesma dedicação que aprende SQL.
✅ Escreva consultas para que outra pessoa consiga mantê-las daqui a cinco anos.
✅ Pense em reutilização: CTEs bem nomeadas, views, procedimentos e controle de versão transformam consultas em patrimônio da equipe.
Conclusão — O que Spock ensinaria sobre SQL
No final desta jornada, percebemos que a diferença entre um analista iniciante e um analista sênior não está na quantidade de comandos SQL decorados. Ambos conhecem SELECT, JOIN, GROUP BY e ORDER BY. O que realmente muda é a forma de pensar.
Spock jamais executaria uma consulta apenas porque ela compila. Ele questionaria a lógica, verificaria as premissas, confrontaria os resultados com outras evidências e só então confiaria na resposta. Essa postura científica é a essência da engenharia de dados.
No universo do IBM Z, onde milhões de transações financeiras, seguros, companhias aéreas e sistemas governamentais dependem da integridade dos dados, um SQL "que funciona" não é suficiente. Ele precisa ser correto, performático, auditável, reutilizável e compreensível.
O verdadeiro crescimento profissional acontece quando o desenvolvedor deixa de perguntar "Como faço esta consulta funcionar?" e passa a perguntar "Como posso garantir que esta informação continuará correta daqui a dez anos?"
Esse é o momento em que um Padawan do COBOL deixa de apenas escrever SQL e começa a pensar como um verdadeiro engenheiro de software — alguém que transforma dados em confiança, lógica em conhecimento e consultas em decisões que movem organizações inteiras.
Como diria o Sr. Spock ao encerrar a missão:
"A consulta mais rápida não é necessariamente a melhor. A melhor é aquela cuja lógica permanece verdadeira, mesmo quando todos os dados do universo são colocados à prova."
