Diferenças entre SQL e NoSQL - Guia de Escolha de Banco de Dados

Tipos de Bancos de Dados

Bancos de dados são divididos principalmente em dois tipos: SQL (relacionais) e NoSQL (não-relacionais). Não é que um seja superior ao outro, mas sim que a escolha adequada ao caso de uso é importante.

SQL (Bancos de Dados Relacionais)

Características

• Armazena dados em tabelas (linhas e colunas)
• Schema (estrutura de dados) definido previamente
• Linguagem de consulta padronizada com SQL
• Garantia de transações com propriedades ACID

-- Definição de tabela
CREATE TABLE users (
  id SERIAL PRIMARY KEY,
  name VARCHAR(100) NOT NULL,
  email VARCHAR(255) UNIQUE NOT NULL,
  created_at TIMESTAMP DEFAULT NOW()
);

CREATE TABLE orders (
  id SERIAL PRIMARY KEY,
  user_id INTEGER REFERENCES users(id),
  total DECIMAL(10, 2),
  status VARCHAR(20)
);

-- Consulta usando relações
SELECT u.name, o.total
FROM users u
JOIN orders o ON u.id = o.user_id
WHERE o.status = 'completed';

Propriedades ACID

Bancos de Dados Representativos

NoSQL

Tipos e Características

1. Tipo Documento

Armazena dados em documentos similares a JSON.

// Exemplo MongoDB
{
  "_id": "user_123",
  "name": "Alice",
  "email": "alice@example.com",
  "orders": [
    { "id": "ord_1", "total": 5000, "items": [...] },
    { "id": "ord_2", "total": 3000, "items": [...] }
  ],
  "preferences": {
    "theme": "dark",
    "language": "pt-br"
  }
}

Exemplos: MongoDB, CouchDB, Firestore

2. Tipo Chave-Valor

Armazena dados em pares simples de chave e valor.

user:123:name → "Alice"
user:123:email → "alice@example.com"
session:abc123 → { "userId": 123, "expires": "..." }

Exemplos: Redis, Amazon DynamoDB, etcd

3. Tipo Colunar

Armazena dados por coluna ao invés de por linha. Adequado para agregações de grandes volumes.

flowchart TB
    subgraph RowBased["Armazenamento por Linha"]
        R1["user_1 | Alice | alice@ex.com"]
        R2["user_2 | Bob | bob@ex.com"]
    end

    subgraph ColumnBased["Armazenamento por Coluna"]
        C1["name → Alice, Bob, ..."]
        C2["email → alice@ex.com, bob@ex.com, ..."]
    end

    RowBased --> ColumnBased

Exemplos: Apache Cassandra, HBase, ClickHouse

4. Tipo Grafo

Armazena dados como relações de nós e arestas.

(Alice)--[FOLLOWS]-->(Bob)
(Alice)--[LIKES]-->(Post1)
(Bob)--[WROTE]-->(Post1)

Exemplos: Neo4j, Amazon Neptune, ArangoDB

Teorema CAP

Teorema que afirma que em sistemas distribuídos, apenas duas das três propriedades a seguir podem ser satisfeitas simultaneamente.

flowchart TB
    subgraph CAP["Teorema CAP"]
        C["Consistency<br/>(Consistência)"]
        A["Availability<br/>(Disponibilidade)"]
        P["Partition Tolerance<br/>(Tolerância a Partição)"]

        CP["CP: MongoDB, Redis Cluster"]
        AP["AP: Cassandra, CouchDB"]
        CA["CA: RDBMS de nó único"]

        C --- CP
        P --- CP
        A --- AP
        P --- AP
        C --- CA
        A --- CA
    end

Exemplos de Classificação

• CP: MongoDB, Redis Cluster
• AP: Cassandra, CouchDB
• CA: RDBMS de nó único (difícil de alcançar em ambiente distribuído)

Tabela Comparativa

Escolha por Caso de Uso

Casos Adequados para SQL

✓ Dados com relações complexas (E-commerce, CRM)
✓ Necessidade de forte consistência de dados (financeiro, gestão de estoque)
✓ Muitas consultas e agregações complexas
✓ Schema estável

Casos Adequados para NoSQL

✓ Necessidade de alto volume de leituras/escritas (redes sociais, IoT)
✓ Schema muda frequentemente
✓ Necessidade de escalabilidade horizontal
✓ Dados geograficamente distribuídos

Exemplos Específicos

Persistência Poliglota

Abordagem de usar múltiplos bancos de dados em uma única aplicação.

flowchart LR
    App["Aplicação E-commerce"]
    App --> PG["PostgreSQL<br/>Produtos, Pedidos, Clientes"]
    App --> Redis["Redis<br/>Sessões, Cache"]
    App --> ES["Elasticsearch<br/>Busca de produtos"]
    App --> Mongo["MongoDB<br/>Reviews, Conteúdo"]

Resumo

A escolha do banco de dados é baseada nas características dos dados, requisitos de escalabilidade e requisitos de consistência. SQL e NoSQL têm uma relação de trade-off, não sendo um superior ao outro. Usando cada um no lugar apropriado e combinando múltiplos bancos de dados conforme necessário, é possível alcançar a arquitetura ideal.