A Religião dos Dados: SQL ou NoSQL qual religião seguir?

Tempo de Leitura: 7 Minutos


A RELIGIÃO DOS DADOS: ESTRUTURAS, DOGMAS E SISTEMAS QUE SUSTENTAM O MUNDO DIGITAL

1. Introdução

A sociedade contemporânea vive conectada, automatizada e cada vez mais mediada por algoritmos.  Constrói sua infraestrutura sobre um elemento aparentemente simples, mas profundamente complexo: os dados. Assim como civilizações passadas gravavam sua história em pedra, depois na argila, com a invenção do pergaminho, em tecidos, ja na era da industrialização, usamos livros e papel, hoje a civilização digital deposita sua memória, suas regras e sua própria continuidade em bancos de dados, que se tornaram verdadeiros santuários da informação.

Dentro da metáfora mística que inspira o título original do vídeo, os bancos de dados funcionam como instituições religiosas modernas: possuem doutrinas (modelos de dados), rituais (consultas, transações), dogmas (formas normais, ACID), heresias (desnormalização indevida), sacerdotes (DBAs) e até divindades (SGBDs gigantes como Oracle, SQL Server e PostgreSQL).

Mas por trás do simbolismo existe uma base técnica fundamental que todo o profissional de TI precisa compreender. São os modelos de dados, estruturas, linguagens, protocolos, fatores de desempenho e diferentes paradigmas arquiteturais. Em especial estudantes e desenvolvedores em formação, que muitas vezes enfrentam a dúvida: qual banco de dados usar?

A resposta não é simples, e é uma questão que pode definir o sucesso ou fracasso de um sistema.

Por isso, agora vamos explorar:

  • Tipos de dados e seus níveis de estruturação

  • Modelos e paradigmas de bancos de dados

  • Formas Normais e o princípio da normalização

  • Quando desnormalizar e por quê

  • Indexação e otimização de consultas

  • Comparação técnica entre os principais SGBDs

  • Como escolher o banco certo para cada projeto

  • Uma visão introdutória sobre bancos NoSQL e usos modernos

Nosso objetivo é construir um material de referência, acadêmico e técnico, acessível tanto para estudantes quanto para profissionais experientes.

2. Dados: Estruturados, Semiestruturados e Não Estruturados

Antes de qualquer discussão sobre SGBDs, é essencial compreender a natureza dos dados.

2.1 Dados Estruturados

São aqueles organizados em um formato rígido e tabular. Exemplos:

  • Tabelas relacionais ou Tabelas de Dados

  • Linhas e colunas com tipos bem definidos

  • Dados numéricos, strings, datas

Características:

  • Altamente pesquisáveis

  • Excelentes para SQL

  • Ideais para análises e padrões repetitivos

SGBDs típicos: Oracle, PostgreSQL, MySQL, SQL Server.

2.2 Dados Semiestruturados

Possuem estrutura, mas flexível e variável.
Exemplos:

  • JSON

  • XML

  • YAML

  • Documentos NoSQL

Características:

  • Esquema flexível

  • Ótimos para APIs

  • Modelos que variam entre elementos

SGBDs típicos: MongoDB, CouchDB, DocumentDB.

2.3 Dados Não Estruturados

Não seguem nenhum formato predefinido. Exemplos:

  • Vídeos, Imagens, Audios, PDFs, Textos brutos

SGBDs típicos: Object Storage (S3, MinIO), ElasticSearch, sistemas distribuídos.

2.4 A escolha começa aqui

A relação entre o tipo de dado e o modelo de banco é direta. Muitos problemas surgem justamente quando dados não estruturados são forçados em modelos estruturados, ou quando modelos flexíveis recebem dados que exigem formalidade.

3. Modelos e Tipos de Bancos de Dados

3.1 Banco de Dados Relacional (SQL)

Dominante há mais de 40 anos, baseado em:

  • Tabelas, Relacionamentos, Integridade referencial, Transações ACID, Linguagem SQL

Pontos fortes: Consistência, Confiabilidade, Padronização, Forte base teórica

Pontos fracos: Escalabilidade horizontal limitada, Modelagem rígida

Principais SGBDs: Oracle, SQL Server, PostgreSQL, MySQL, MariaDB, SQLite (embedded)

3.2 Bancos NoSQL

Criados para atender demandas de escalabilidade, flexibilidade de schema e alta performance.

Principais categorias:

  1. Documentos – MongoDB, CouchDB

  2. Chave-Valor – Redis, DynamoDB

  3. Grafos – Neo4j, ArangoDB

  4. Wide-Column – Cassandra, HBase

Usos comuns: Big Data, Sistemas distribuídos, APIs flexíveis, Ambientes com alto volume e baixa latência

4. Normalização: As Formas Normais

A normalização é o processo de organizar dados para se adaptarem aos SGDBs Relacionais ou SQL, seu objetivo é Reduzir redundância, Garantir integridade, Evitar inconsistências.

Ela é baseada nas Formas Normais, cada uma corrigindo um tipo de problema.

4.1 Primeira Forma Normal (1FN)

Regras: Sem valores multivalorados, Sem repetições, Colunas atômicas.
Problema resolvido: duplicações e colunas “listas”.

4.2 Segunda Forma Normal (2FN)

Regras: Estar em 1FN, Remover dependências parciais de chaves compostas.
Problema resolvido: colunas que dependem apenas de parte da chave primária.

4.3 Terceira Forma Normal (3FN)

Regras: Estar em 2FN, Remover dependências transitivas.
Problema resolvido: separa atributos derivados de outros atributos que não são chave.

4.4 Forma Normal de Boyce-Codd (BCNF)

Mais rígida que 3FN; corrige anomalias não resolvidas.

4.5 Outras Formas Normais

4FN, 5FN — raramente aplicadas em projetos comuns.

5. Desnormalização: Quando a Heresia Faz Sentido

Desnormalizar não é quebrar regras, é aplicá-las de forma estratégica.

Usos comuns: Otimizar leitura, Reduzir JOINs pesados, Criar tabelas de agregação, Suporte a relatórios em tempo real

Desnormalizar traz custo de escrita, mas aumenta velocidade de leitura.

É comum em: Sistemas analíticos, Data Warehouses, Bancos orientados a performance, Tabelas de cache

6. Indexação: O Coração da Performance

Sem índices, um SGBD faz full scans, ou seja, varreduras completas.

Tipos comuns de índices

  • B-Tree: padrão universal

  • Hash: buscas exatas, não serve para ranges

  • GiST / GIN: PostgreSQL (ideal para JSON e full-text)

  • Índices compostos: mais de uma coluna

  • Índices exclusivos: garantem unicidade

Problemas comuns

  • Índices demais prejudicam performance de escrita

  • Índices mal escolhidos não ajudam em nada

  • Índices compostos são sensíveis à ordem das colunas

Ferramentas úteis

  • EXPLAIN – Mostra o que o otimizador de consulta interno vai executar e em alguns casos o custo computacional desta operação por registro.

  • ANALYZE – Analisador que otimiza e identifica possíveis gargalos de execução ou processos com os maiores custos computacionais

  • Query Planner

  • Otimização baseada em estatísticas

7. Otimização de Consultas

Técnicas principais:

  1. Evitar SELECT *

  2. Utilizar LIMIT em consultas amplas

  3. Garantir filtros adequados, aplicados na ordem mais restritiva até a menos restritiva, priorizando compos com indices ou ordem natural do banco (materialized)

  4. Usar índices apropriados

  5. Evitar JOINs desnecessários, principalmente uso de Left Join e Outer Join que geralmente possuem maiores custos computacionais e de leitura

  6. Normalizar regras de negócio na aplicação

  7. Cachear resultados repetitivos

Recursos avançados:

  • Materialized Views

  • Partitioning

  • Sharding

  • Caching distribuído (Redis)

8. Comparação Técnica entre os Principais SGBDs

8.1 Oracle

Prós: Extremo poder transacional, Ferramentas de análise e clustering avançadas, Suporte empresarial robusto

Contras: Licenciamento caro, Complexidade elevada

8.2 Microsoft SQL Server

Prós: Excelente integração com ecossistema Microsoft, Ferramentas visuais de alto nível, Muito eficiente em BI

Contras: Custo de licença, Mais adequado a ambientes Windows (apesar do suporte ao Linux)

8.3 PostgreSQL

Prós: Open source, Extensível, Suporte avançado a JSON, Índices complexos (GIN, GiST)

Contras: Curva de aprendizado em tuning, Pode exigir conhecimento avançado para ambientes de alta escala

8.4 MySQL

Prós: Fácil de iniciar, Muito usado em projetos web, Grande comunidade

Contras: Menos recursos avançados que PostgreSQL, Algumas engines (ex: MyISAM) são fracas em consistência

8.5 MariaDB

Prós: Fork mais moderno do MySQL, Melhor performance em certas operações

Contras: Menor adoção corporativa que MySQL

8.6 SQLite

Prós: Zero configuração, Embutido em aplicações, Extremamente leve, Ideal para mobile, IoT, aplicações locais

Contras: Não é multiusuário, Limitado para cenários de alto volume

SQLite é uma “Bíblia de bolso”: pequena, eficiente, confiável, sempre presente.

9. Introdução Prática aos Bancos NoSQL

Cada categoria resolve um tipo de problema.

9.1 Documentos (MongoDB)

Próprio para dados complexos, flexíveis e mutáveis.

9.2 Chave-Valor (Redis)

Cache, sessões, filas.

9.3 Grafos (Neo4j)

Relações profundas e redes complexas.

9.4 Wide-Column (Cassandra)

Altíssima escalabilidade horizontal.

10. A Dor do Desenvolvedor: Como Escolher

Perguntas chave:

  • Qual o tipo de dado predominante?

  • O sistema prioriza leitura ou escrita?

  • É distribuído?

  • Precisa ser altamente escalável?

  • Há necessidade de forte integridade transacional?

Filosofia moderna:

Não existe o “melhor banco”.
Existe o que é mais adequado à necessidade.

Estratégia recomendada:

Arquitetura Poliglota de Dados
— Usar múltiplos bancos no mesmo sistema.

Exemplo prático:

  • PostgreSQL para dados estruturados

  • MongoDB para documentos

  • Redis para cache

  • S3/MinIO para objetos

  • Elasticsearch para pesquisa

O desenvolvedor encontra a “salvação” quando compreende que a resposta não é escolher um, e sim combinar.

11. Conclusão

O universo dos dados é profundo, complexo e ainda em expansão. Bancos SQL e NoSQL coexistem como escolas teóricas diferentes, mas complementares. O profissional moderno precisa dominar ambos e entender a fundo suas estruturas, vantagens e limitações.

Quando conhecemos os fundamentos — tipos de dados, modelos, normalização, indexação e otimização — nossas escolhas deixam de ser baseadas em tradição ou preferência pessoal e passam a ser guiadas pela engenharia.

Referências Sugeridas

C. J. Date — An Introduction to Database Systems
Thomas Connolly & Carolyn Begg — Database Systems: A Practical Approach
Documentation PostgreSQL, Oracle, SQL Server, MySQL, MariaDB
Martin Kleppmann — Designing Data-Intensive Applications

Trilha de Aprendizado Recomendada

  1. Fundamentos de modelagem de dados

  2. Álgebra relacional

  3. SQL avançado

  4. Normalização e desnormalização

  5. Indexação e planos de execução

  6. Arquitetura de SGBDs

  7. NoSQL e sistemas distribuídos

  8. Cache, mensageria e microserviços

  9. Engenharia de dados e pipelines

  10. Observabilidade e monitoramento