 |
| Bellacosa Mainframe numa guerra que nunca existiu sql versus nosql |
☕ Um Café no Bellacosa Mainframe
SQL versus NoSQL: A Guerra que Nunca Existiu (e por que todo Programador COBOL deveria entender os dois)
"A tecnologia muda. Os princípios permanecem."
Imagine que você acabou de entrar em uma grande empresa. É seu primeiro emprego como programador COBOL. Você acabou de aprender JCL, já conseguiu fazer seu primeiro programa rodar no z/OS, descobriu o que é um Job, um Dataset e finalmente conseguiu fazer um SELECT sem esquecer o END-EXEC.
Então alguém da equipe comenta durante uma reunião:
"Estamos integrando o Mainframe com MongoDB."
Cinco minutos depois outro colega fala:
"Os dados vão para Redis."
Na sequência o arquiteto comenta:
"O Neo4j será usado para análise de fraude."
Você pensa:
"Mas... eu aprendi SQL... o que aconteceu? Agora existem quatro bancos diferentes?"
Bem-vindo ao desenvolvimento moderno.
Hoje vamos conversar sobre uma das maiores dúvidas de quem está começando:
SQL ou NoSQL?
Spoiler...
A resposta é muito diferente do que a internet costuma vender.
Pegue seu café.
Vamos conversar.
O mito da guerra
Existe uma narrativa que aparece em vídeos, blogs e redes sociais dizendo que:
SQL morreu.
Ou então:
NoSQL veio substituir os bancos relacionais.
Nada poderia estar mais distante da realidade.
Na verdade, SQL nunca esteve tão vivo.
E NoSQL nunca tentou matá-lo.
Os dois nasceram para resolver problemas completamente diferentes.
É como comparar:
Qual é melhor?
Depende.
Você quer transportar cimento entre cidades?
Ou cruzar o oceano?
A pergunta está errada.
Da mesma forma:
A pergunta nunca foi SQL versus NoSQL.
A pergunta correta sempre foi:
Qual tecnologia resolve melhor ESTE problema?
Uma pequena viagem no tempo
Imagine que estamos em 1970.
Os computadores ocupavam salas inteiras.
Não existia internet.
Não existia smartphone.
Nem notebook.
Muito menos Cloud.
Os bancos de dados funcionavam quase como arquivos gigantes.
Era preciso conhecer exatamente onde cada informação estava gravada.
Era complicado.
Foi então que um pesquisador da IBM chamado Edgar Frank Codd publicou um artigo que mudaria para sempre a computação:
A Relational Model of Data for Large Shared Data Banks
Esse trabalho apresentou uma ideia brilhante.
Em vez de pensar em ponteiros físicos...
Vamos pensar em relações.
Assim nasceram:
tabelas
linhas
colunas
chaves
relacionamentos
Nascia o Modelo Relacional.
Poucos anos depois, a própria IBM desenvolveu o System R, um projeto experimental que introduziu a linguagem SQL (Structured Query Language). A ideia mostrou tanto potencial que outras empresas passaram a investir no modelo, surgindo plataformas como Oracle, Informix, SQL Server, PostgreSQL, MySQL e, naturalmente, o Db2, um dos pilares do universo IBM Mainframe.
Por que o SQL fez tanto sucesso?
Porque ele resolveu um problema gigantesco.
Imagine um banco.
Existem milhões de clientes.
Cada cliente possui:
conta corrente
poupança
investimentos
cartões
empréstimos
Tudo isso precisa estar relacionado.
Se João mudar de endereço...
Não faz sentido atualizar vinte lugares diferentes.
O SQL organiza essas informações em tabelas relacionadas, reduzindo redundâncias e garantindo consistência.
Esse conceito recebe o nome de normalização.
Parece um detalhe.
Na prática...
Economizou bilhões de dólares em armazenamento ao longo da história.
ACID: o superpoder invisível
Existe um conceito que todo programador júnior deveria decorar.
ACID.
Não porque cai em entrevista.
Mas porque explica por que bancos confiam tanto em SQL.
Imagine transferir R$ 500 de uma conta para outra.
São duas operações:
retirar da Conta A
adicionar na Conta B
E se faltar energia exatamente no meio?
ACID garante que isso não aconteça.
Ou tudo acontece...
Ou nada acontece.
Isso é chamado de Atomicidade.
Depois temos:
Consistência
Os dados permanecem válidos.
Isolamento
Milhares de pessoas podem operar simultaneamente sem "atropelar" umas às outras.
Durabilidade
Depois do COMMIT...
Mesmo que o servidor desligue...
Os dados continuam lá.
É por isso que bancos, seguradoras e bolsas de valores continuam confiando em bancos relacionais.
Onde entra o Mainframe?
Agora vem uma curiosidade que muita gente desconhece.
Grande parte do dinheiro que circula diariamente no mundo passa por Mainframes.
Cartões.
PIX.
TED.
DOC.
Compras internacionais.
Folha de pagamento.
Seguros.
Tudo isso frequentemente passa por sistemas COBOL utilizando Db2 for z/OS.
Quando você escreve:
EXEC SQL
SELECT SALDO
INTO :WS-SALDO
FROM CONTAS
WHERE NUMERO = :WS-CONTA
END-EXEC.
O SQL não está apenas buscando dados.
Existe todo um universo trabalhando por trás:
Pré-compilador SQL
DBRM
Package
Bind
Plan
Otimizador
Buffer Pools
Logging
Locking
Recovery
O desenvolvedor enxerga apenas a ponta do iceberg.
Então por que surgiu o NoSQL?
Porque o mundo mudou.
Muito.
Em 1970 ninguém imaginava redes sociais.
Nem streaming.
Nem IoT.
Nem celulares.
Nem milhões de fotos por minuto.
Agora imagine armazenar:
vídeos
comentários
curtidas
localização
mensagens
sensores
documentos JSON
Tudo isso em tabelas relacionais.
Funciona?
Sim.
Mas nem sempre é a melhor escolha.
Foi então que surgiu o movimento NoSQL.
Curiosamente...
NoSQL não significa "Sem SQL".
Significa:
Not Only SQL
Ou seja...
Existem outros modelos além do relacional.
Os quatro reinos do NoSQL
Quando alguém diz "NoSQL", na verdade está falando de uma família inteira de bancos.
📄 Documento
Exemplo:
MongoDB.
Os dados ficam parecidos com JSON.
Cada documento pode possuir uma estrutura diferente.
Perfeito para aplicações web.
🔑 Chave-Valor
Exemplo:
Redis.
Imagine um gigantesco dicionário.
Você fornece uma chave.
Recebe um valor.
Extremamente rápido.
Muito utilizado como cache.
📚 Colunar
Exemplos:
Cassandra.
ScyllaDB.
HBase.
Projetados para trabalhar com enormes volumes distribuídos.
Muito utilizados em Big Data.
🌐 Grafos
Exemplo:
Neo4j.
Aqui o importante não são os registros.
São os relacionamentos.
Quem conhece quem?
Quem comprou junto?
Quem transferiu dinheiro para quem?
Ideal para detectar fraudes.
SQL é rígido?
Sim.
E isso é uma vantagem.
Imagine um cadastro de funcionários.
Todos possuem:
matrícula
nome
salário
departamento
É ótimo exigir que todos tenham exatamente a mesma estrutura.
Já em uma rede social...
Cada usuário pode possuir informações diferentes.
Uns possuem Instagram.
Outros TikTok.
Outros LinkedIn.
Outros nenhum.
Forçar uma estrutura única pode ser desnecessário.
É aí que bancos orientados a documentos brilham.
Escalabilidade
Existe outra diferença importante.
Tradicionalmente, bancos SQL cresceram na vertical.
Mais CPU.
Mais memória.
Mais discos.
Servidor maior.
Já muitos bancos NoSQL foram desenhados pensando em crescer horizontalmente.
Mais servidores.
Mais nós.
Mais máquinas.
É o modelo utilizado por empresas como Google, Amazon, Netflix e Meta.
Mas atenção: hoje essa divisão não é absoluta. Bancos relacionais modernos também oferecem mecanismos de escalabilidade horizontal, e diversas soluções NoSQL implementam recursos avançados de consistência e transações.
SQL também evoluiu
Existe outro mito.
"O SQL parou no tempo."
Errado.
Hoje temos:
Os bancos relacionais modernos absorveram diversas características que antes eram exclusivas do NoSQL.
NoSQL também evoluiu
MongoDB hoje possui:
transações
índices sofisticados
agregações complexas
Redis deixou de ser apenas cache.
Neo4j suporta consultas extremamente sofisticadas.
Cassandra possui consistência configurável.
Ou seja...
Os mundos estão convergindo.
O conceito mais importante: Polyglot Persistence
Se existe uma expressão que todo desenvolvedor moderno deveria conhecer é esta:
Polyglot Persistence.
Ela significa:
usar o banco certo para cada problema.
Imagine um banco digital.
Ele pode utilizar:
Db2 → contas correntes
MongoDB → documentos
Redis → cache
Neo4j → fraude
Elastic → pesquisa
Banco Vetorial → IA
Tudo funcionando junto.
Não existe regra dizendo que um sistema deve possuir apenas um banco.
O papel do COBOL nessa história
Aqui existe um enorme equívoco.
Muitos imaginam que COBOL só conversa com Db2.
Hoje isso está longe da realidade.
Aplicações COBOL podem consumir:
REST APIs.
MQ.
Kafka.
gRPC.
z/OS Connect.
Eventos.
Microsserviços.
E esses serviços podem acessar MongoDB, Redis ou qualquer outro banco moderno.
O COBOL continua sendo o cérebro transacional.
Os demais componentes ampliam suas capacidades.
Dicas para quem está começando
Se eu pudesse aconselhar um programador júnior, seguiria esta ordem:
Aprenda modelagem de dados.
Domine SQL.
Entenda normalização.
Aprenda índices.
Estude planos de acesso.
Descubra como funciona um otimizador.
Aprenda transações.
Depois estude MongoDB.
Conheça Redis.
Descubra Neo4j.
Aprenda APIs REST.
Entenda eventos e mensageria.
A tecnologia muda.
Os fundamentos permanecem.
Curiosidades que pouca gente conhece
☕ O primeiro grande projeto SQL da IBM chamava-se System R.
☕ O Db2 nasceu dentro da IBM justamente para materializar as ideias do modelo relacional em ambientes corporativos.
☕ O comando SELECT * é um dos mais utilizados por iniciantes... e um dos menos recomendados em produção. Buscar apenas as colunas necessárias reduz tráfego de dados e melhora o desempenho.
☕ Muitos sistemas bancários escritos há mais de 30 anos continuam processando milhões de transações diariamente com desempenho impressionante.
☕ Redis consegue responder consultas em microssegundos porque mantém os dados principalmente em memória.
☕ Neo4j foi inspirado na Teoria dos Grafos, um ramo da matemática muito mais antigo do que os computadores.
☕ Diversos bancos NoSQL utilizam conceitos publicados em artigos científicos da Google e da Amazon sobre sistemas distribuídos, como Bigtable, Dynamo e MapReduce.
☕ O termo NoSQL surgiu como um movimento alternativo, mas acabou sendo reinterpretado como Not Only SQL, refletindo melhor a realidade atual.
Easter Eggs Bellacosa Mainframe 🥚
🔍 Easter Egg #1 – O herói invisível
Sempre que você executa um SELECT no Db2, existe um componente trabalhando silenciosamente para decidir o melhor caminho de acesso: o otimizador de consultas. Ele é como o GPS do banco de dados. Você não o vê, mas ele escolhe a rota mais eficiente.
🥚 Easter Egg #2 – O COBOL nunca pergunta "como"
Um programa COBOL com Embedded SQL apenas descreve o que deseja. Quem decide como buscar os dados é o Db2. Essa separação entre intenção e estratégia foi uma das grandes revoluções introduzidas pelo SQL.
🥚 Easter Egg #3 – O Mainframe conversa com o futuro
Um programa COBOL criado na década de 1990 pode, com poucas adaptações, consumir uma API REST hospedada na nuvem que, por sua vez, grava documentos em MongoDB e publica eventos em Kafka. O legado não é um obstáculo: ele pode ser parte da arquitetura moderna.
🥚 Easter Egg #4 – Nem tudo é tabela
Quando você olhar para uma árvore genealógica, uma rede social ou um mapa de rotas aéreas, pense em grafos. Quando observar um catálogo de produtos com atributos diferentes para cada item, pense em documentos. Quando acessar seu extrato bancário, pense em tabelas relacionais. O segredo está em reconhecer o problema antes de escolher a ferramenta.
Conclusão
No fim das contas, SQL e NoSQL não são adversários. São aliados que nasceram em épocas diferentes para enfrentar desafios distintos. O SQL continua sendo o alicerce dos sistemas críticos que exigem consistência, integridade e confiabilidade — exatamente o tipo de ambiente onde o IBM Z e o Db2 brilham há décadas. Já o NoSQL oferece flexibilidade, escalabilidade e modelos especializados que complementam essas capacidades em aplicações modernas, distribuídas e orientadas a dados.
Se você está iniciando sua jornada como programador COBOL ou desenvolvedor Mainframe, não caia na armadilha dos modismos. Aprenda primeiro os fundamentos: modelagem de dados, SQL, índices, transações e otimização de consultas. Esses conhecimentos acompanharão toda a sua carreira. Depois, expanda seus horizontes estudando MongoDB, Redis, Cassandra, Neo4j e outras tecnologias que fazem parte das arquiteturas atuais.
Lembre-se sempre de uma filosofia muito presente no universo Bellacosa Mainframe:
Um excelente desenvolvedor não é aquele que conhece todas as ferramentas, mas aquele que sabe exatamente quando usar cada uma delas.
No mundo do IBM Z, onde convivem sistemas escritos há décadas com APIs, microsserviços, inteligência artificial e computação em nuvem, essa capacidade de escolher a tecnologia certa é o que transforma um programador júnior em um verdadeiro arquiteto de soluções. Afinal, o futuro não pertence ao SQL nem ao NoSQL. Ele pertence aos profissionais que compreendem ambos e conseguem fazê-los trabalhar juntos.
