SQL vs NoSQL: qual a base de dados que a sua app deve usar?

As bases de dados SQL (também chamadas relacionais) guardam os dados em tabelas com uma estrutura definida — linhas e colunas — e ligam tabelas relacionadas entre si. Consulta-se com a linguagem SQL. O Postgres, o MySQL e o SQLite são exemplos. As bases de dados NoSQL usam outras formas de guardar dados — documentos, pares chave-valor, colunas largas ou grafos — e normalmente permitem uma estrutura mais flexível. O MongoDB, o Redis, o DynamoDB e o Firestore são exemplos. Para a maioria das apps de negócio, uma base SQL é a escolha sensata por defeito; o NoSQL brilha em tarefas específicas.

Porque é que esta escolha importa ao criar com IA

A base de dados é uma das partes mais difíceis de mudar numa app mais tarde. Os ecrãs podem ser redesenhados numa tarde; mudar anos de dados de clientes para um tipo diferente de base de dados é um projeto.

Quando um criador de apps com IA acrescenta armazenamento de dados por si, está a escolher uma destas opções. Perceber a diferença ajuda-o a:

• Compreender como são os seus dados e se conseguem responder às perguntas que fará mais tarde (« receitas por mês por produto »).
• Avaliar as escolhas de plataforma. Algumas plataformas assentam numa base de documentos, outras numa base relacional. Veja Supabase vs Firebase para um exemplo comum de cada.
• Evitar dependência de fornecedor. O SQL é um padrão partilhado, por isso os dados relacionais costumam ser mais fáceis de mudar entre fornecedores.

Uma analogia do dia a dia

Uma base de dados SQL é como um conjunto de folhas de cálculo bem desenhadas, com colunas rígidas: uma folha para os clientes, outra para as encomendas, e cada linha de encomenda aponta para uma linha de cliente através de um ID. Todas as linhas de uma folha têm as mesmas colunas. Exige algum planeamento, mas fazer perguntas que cruzem folhas é fácil e os dados ficam organizados.

Uma base de dados de documentos NoSQL é como um arquivo de pastas. A pasta de cada cliente pode conter os seus dados e as suas encomendas todos juntos, e uma pasta pode ter papéis extra que as outras não têm. Ir buscar toda a história de um cliente é rápido. Responder a « o que é que toda a gente encomendou no mês passado? » obriga a abrir muitas pastas.

As diferenças reais

« NoSQL » não é uma coisa só. Os principais tipos:

Um exemplo prático: os mesmos dados de uma loja, de duas formas

Imagine uma pequena loja online com uma cliente e as suas encomendas.

SQL (relacional): os dados estão divididos em tabelas e ligados por IDs.

-- customers: id=1, name='Lena Ortiz'
-- orders:    id=101, customer_id=1, total=42.00
--            id=103, customer_id=1, total=25.00

SELECT c.name, SUM(o.total)
FROM customers c JOIN orders o ON o.customer_id = c.id
GROUP BY c.name;

Se a Lena mudar o email, muda num único sítio. Perguntar « total de vendas por cliente este mês » é uma só consulta.

NoSQL (documento): as encomendas dela podem viver dentro do seu próprio documento.

{
  "_id": "cust_1",
  "name": "Lena Ortiz",
  "email": "lena@example.com",
  "orders": [
    { "id": 101, "total": 42.00, "items": ["Green tea"] },
    { "id": 103, "total": 25.00, "items": ["Teapot"] }
  ]
}

Carregar a página de perfil da Lena com todas as suas encomendas é uma única leitura. Mas as perguntas que atravessam todos os clientes — o produto mais vendido este mês — dão mais trabalho, e se os mesmos detalhes do produto forem copiados para muitas encomendas, manter tudo sincronizado passa a ser responsabilidade da app.

Nenhuma está errada. A questão é qual o padrão que a sua app usa mais.

Como escolher

Uma base relacional SQL costuma ser a escolha certa por defeito se:

• Os seus dados têm muitas relações: utilizadores, equipas, marcações, faturas, produtos.
• Vai precisar de relatórios, filtros e totais entre registos.
• A correção é importante: dinheiro, níveis de stock, permissões.

Vale a pena considerar uma base NoSQL se:

• Precisa de uma cache ou de um armazenamento de sessões rápido — o Redis é comum aqui, muitas vezes em conjunto com uma base SQL.
• Os seus registos são muito numerosos, simples e independentes, como registos de eventos ou leituras de sensores.
• Está numa plataforma construída em torno de uma delas, como o Firestore do Firebase, e as funcionalidades em tempo real são o principal atrativo.

Muitas apps usam as duas: SQL como fonte principal de verdade, e um armazenamento NoSQL para cache ou para uma funcionalidade específica.

Termos-chave

Ideias erradas comuns

• « NoSQL significa não ter esquema. » Os seus dados têm sempre uma forma. Com NoSQL, a base de dados pode não a impor, por isso o seu código tem de a impor.
• « SQL não escala. » As bases relacionais suportam serviços de dimensão enorme. A maioria das apps nunca se aproxima dos seus limites.
• « NoSQL é sempre mais rápido. » Só para os padrões para os quais foi concebida. Um relatório que atravesse dados todos pode ser mais lento.
• « Tem de escolher uma para sempre. » Muitas apps combinam ambas. E bases SQL como o Postgres também guardam JSON, por isso alguns campos flexíveis não exigem NoSQL.
• « NoSQL significa que não pode usar SQL. » O nome costuma ser lido como « não apenas SQL », e alguns produtos NoSQL oferecem linguagens de consulta semelhantes a SQL.

O que perguntar ao seu criador com IA

• « Que tipo de base de dados usa esta app e porque é que se adapta bem aos meus dados? »
• « Desenha as tabelas ou coleções e a forma como se relacionam. »
• « Que relatórios vou querer daqui a seis meses? Esta base consegue respondê-los facilmente? »
• « Se alguns campos forem mesmo flexíveis, guarda-os como JSON no Postgres em vez de acrescentar uma segunda base de dados. »
• « Acrescenta uma cache só se tivermos um problema de velocidade medido. »

Bases de dados no Mythex

O Mythex dá a cada projeto que precisa de uma base de dados uma base Postgres dedicada — uma base SQL relacional — acrescentada quando a app a exige, seja pedindo no chat seja com o comando /database (Database). Isto serve a maioria das apps de negócio: utilizadores, marcações, encomendas e relatórios. Se precisar de um serviço externo específico, como uma base de documentos alojada, o agente pode escrever código que se liga a ela com chaves que guarda como segredos do projeto. Para saber mais sobre a própria linguagem, leia o que é SQL.

Perguntas