SQL e NoSQL

Um modelo de dados é uma forma de pensar

Todo banco guarda dados. O que muda é o modelo: a forma como os dados são organizados, como se relacionam e como são consultados. O modelo decide quais perguntas ficam fáceis de responder e quais exigem esforço.

Para comparar, vamos usar o mesmo exemplo em todos os modelos: uma loja com clientes, pedidos e os itens de cada pedido.

O modelo relacional

No modelo relacional, os dados ficam em tabelas com colunas definidas. Cada tipo de coisa tem a sua tabela, e os relacionamentos são feitos por chaves: o pedido guarda o identificador do cliente, e o item guarda o identificador do pedido.

CREATE TABLE clientes (
  id    BIGINT GENERATED ALWAYS AS IDENTITY PRIMARY KEY,
  nome  TEXT NOT NULL,
  email TEXT NOT NULL UNIQUE
);

CREATE TABLE pedidos (
  id         BIGINT GENERATED ALWAYS AS IDENTITY PRIMARY KEY,
  cliente_id BIGINT NOT NULL REFERENCES clientes (id),
  status     TEXT NOT NULL,
  criado_em  TIMESTAMPTZ NOT NULL DEFAULT now()
);

CREATE TABLE itens_pedido (
  pedido_id  BIGINT NOT NULL REFERENCES pedidos (id),
  produto_id BIGINT NOT NULL,
  quantidade INT NOT NULL CHECK (quantidade > 0)
);

O banco garante as regras declaradas: não aceita um pedido de um cliente que não existe, nem um item com quantidade zero. Para montar a tela de um pedido, a consulta junta as tabelas:

SELECT p.id, p.status, c.nome, i.produto_id, i.quantidade
FROM pedidos p
JOIN clientes c ON c.id = p.cliente_id
JOIN itens_pedido i ON i.pedido_id = p.id
WHERE p.id = 981;

Três características definem o modelo:

• Esquema na escrita: o formato dos dados é declarado antes, e o banco recusa o que não cabe nele.
• Cada informação num só lugar: o nome do cliente está na tabela de clientes e em nenhum outro lugar. Mudou, mudou para todos os pedidos.
• Consultas que ninguém previu: o SQL combina as tabelas de qualquer forma. Um relatório novo não exige mudar a estrutura.

Os bancos relacionais também oferecem transações: um conjunto de operações que acontece por inteiro ou não acontece. Criar o pedido e os itens fica numa transação, e nunca sobra um pedido sem itens por causa de uma falha no meio. O tópico de transações explica as garantias em detalhe.

NoSQL: um nome para várias famílias

"NoSQL" significa not only SQL. O nome agrupa bancos que não seguem o modelo relacional, mas eles têm pouco em comum entre si. São quatro famílias principais.

Documentos

Cada registro é um documento, parecido com um JSON, que pode conter listas e objetos aninhados. Os dados que costumam ser lidos juntos ficam juntos.

{
  "_id": 981,
  "status": "enviado",
  "cliente": { "id": 42, "nome": "Marina Souza" },
  "itens": [
    { "produtoId": 7, "quantidade": 2 },
    { "produtoId": 15, "quantidade": 1 }
  ]
}

A tela do pedido sai de uma única leitura, sem junções. Em troca, o nome do cliente agora está copiado em cada pedido. Se ele mudar, alguém precisa decidir se os pedidos antigos são atualizados. Exemplos: MongoDB, Couchbase, Firestore.

Chave-valor

O modelo mais simples: uma chave aponta para um valor, e o banco não sabe nada sobre o conteúdo. A única consulta é "me dê o valor desta chave". Em troca, ele é extremamente rápido. Muito usado para cache, sessões e contadores. Exemplos: Redis, Memcached e, com recursos a mais, DynamoDB.

Colunares de linha larga

Os dados são organizados pela forma como serão lidos, em partições distribuídas por várias máquinas. Aceitam volumes enormes de escrita, mas cada consulta precisa ser planejada no desenho da tabela. Exemplos: Cassandra, ScyllaDB, Bigtable.

Grafos

Os dados são nós ligados por arestas, e os relacionamentos são o centro do modelo. Perguntas como "amigos de amigos que compraram este produto" são naturais aqui e caras em qualquer outro modelo. Exemplos: Neo4j, Neptune.

Onde a diferença realmente está

A diferença central é quem cuida da integridade e da forma dos dados. No relacional, o banco cuida. No modelo de documentos, a aplicação assume essa responsabilidade em troca de flexibilidade e de leituras mais simples.

Por que isso importa quando a IA escreve o código

Um assistente monta o acesso a qualquer banco com a mesma facilidade, e aceita a escolha que vier no pedido. Os problemas aparecem meses depois:

• Um MongoDB escolhido "porque é flexível" acumula documentos em formatos diferentes, e cada consulta precisa tratar todos eles.
• Dados copiados em vários documentos ficam inconsistentes, porque só um lugar foi atualizado.
• Um relatório simples exige juntar coleções na aplicação, com dezenas de consultas.
• Um banco relacional é usado como fila ou como cache de alto volume, e sofre.

O próximo nível compara os modelos em detalhe e mostra como escolher.