Bancos de Dados

Relacional vs NoSQL — conceitos, diferenças e quando usar cada modelo.

Modelo Relacional

Dados organizados em tabelas. Schema fixo. Relacionamentos via chaves estrangeiras. SQL padronizado.

Banco	Destaque
PostgreSQL	open source, recursos avançados, JSONB, extensões, escalável
MySQL / MariaDB	popular em web, rápido em leitura, ecossistema grande
SQLite	embutido, arquivo único, zero configuração
Oracle	enterprise, alto desempenho, licença cara
SQL Server	Microsoft, integração Windows/Azure

ACID

ACID (Relacional)

AAtomicidade — tudo ou nada

CConsistência — estado sempre válido

IIsolamento — transações não interferem

DDurabilidade — commit sobrevive a falhas

BASE (NoSQL)

BBasically Available — disponibilidade priorizada

SSoft state — estado pode mudar sem input

EEventually consistent — consistência eventual

Normalização

Elimina redundância e dependências anômalas. Tradeoff: mais integridade, mais joins.

Forma Normal	Regra
1NF	colunas atômicas, sem grupos repetidos
2NF	1NF + atributos dependem da PK inteira (sem dependência parcial)
3NF	2NF + sem dependências transitivas (A→B→C onde B não é chave)
BCNF	3NF mais estrita — toda dependência funcional parte de superkey

Desnormalização: intencional para performance — duplicar dados para evitar joins custosos. Tradeoff: leitura mais rápida, escrita mais complexa.

NoSQL

"Not Only SQL" — modelos de dados alternativos ao relacional. Surgiu para escala horizontal, schema flexível e casos de uso específicos.

Tipos de NoSQL

Document Store

MongoDB · CouchDB · Firestore

JSON/BSON por documento. Schema flexível. Ideal: catálogos, perfis, conteúdo heterogêneo.

Key-Value

Redis · DynamoDB · Memcached

Par chave → valor. O(1). Ideal: cache, sessions, rate limiting, filas.

Wide-Column

Cassandra · HBase · ScyllaDB

Linhas com colunas variáveis. Escala massiva. Ideal: time-series, IoT, logs.

Graph

Neo4j · Neptune · ArangoDB

Nós e arestas. Ideal: redes sociais, recomendações, detecção de fraude.

Time-Series

InfluxDB · TimescaleDB · Prometheus

Otimizado para dados com timestamp. Ideal: métricas, sensores, observabilidade.

BASE

Modelo de consistência alternativo ao ACID, adotado por muitos bancos NoSQL distribuídos. Prioriza disponibilidade sobre consistência imediata.

CAP Theorem

Em sistema distribuído com particionamento de rede, é impossível garantir Consistência, Disponibilidade e Tolerância a Partição simultaneamente.

Consistência

todos os nós veem os mesmos dados

Disponibilidade

toda request recebe resposta

Partição

tolera falha de rede entre nós

escolhe C + A

PostgreSQL · MySQL (single node)

escolhe C + P

MongoDB · HBase · Redis

escolhe A + P

Cassandra · CouchDB · DynamoDB

Quando usar cada

Use	Quando
Relacional	schema estável, relacionamentos complexos, transações críticas (financeiro, pedidos), relatórios ad-hoc, consistência > escala
Document	schema varia por registro, dados hierárquicos, iteração rápida sem migrações, escala horizontal de escrita
Key-Value	cache/session, latência µs, dados simples sem estrutura
Wide-Column	escrita massiva distribuída, time-series, sem joins
Graph	relacionamentos são o core, múltiplos graus de separação, recomendações

Comparativo

Critério	Relacional	Document	Key-Value	Wide-Column
Schema	rígido	flexível	nenhum	semi-flexível
Joins	nativo	limitado ($lookup)	não	não
Escala	vertical	horizontal	horizontal	horizontal
ACID	sim	parcial*	não	não
Consistência	forte	configurável	eventual	eventual
Query	SQL	MQL / API	get/set	CQL

* MongoDB tem transações multi-documento desde v4.0

Schema Design NoSQL

Embed (incorporar)

Dados sempre acessados juntos. Relação 1:poucos. Ciclo de vida igual ao pai.

{ "_id": "u1", "name": "Alfredo",
  "addresses": [
    { "city": "SP", "zip": "01310" }
  ]
}

Reference (referenciar)

Dados acessados independentemente. Relação 1:muitos. Ciclo de vida próprio.

{ "_id": "u1", "name": "Alfredo" }

{ "_id": "o1", "userId": "u1",
  "total": 150 }

Índices

Estrutura de dados auxiliar para acelerar queries. Presente em todos os bancos. Tradeoff: leitura mais rápida, escrita mais lenta.

Tipo	Uso
B-tree	igualdade, range, ORDER BY — padrão na maioria
Hash	só igualdade, mais rápido que B-tree para isso
Full-text	busca textual (LIKE, palavras)
Geoespacial	distância, área, coordenadas
Composto	múltiplos campos — ordem importa

Regra: crie índice nos campos usados em WHERE, JOIN ON, ORDER BY. Evite índices em colunas com poucos valores distintos (boolean, status com 2 valores).