Questão de Banco de Dados — Banco de Dados — Quadrix 2025

Bancos de dados NoSQL: escolha por adequação, não por dogma

Gabarito: ERRADO (letra E). A afirmação de que bancos NoSQL são "sempre a melhor escolha para grandes volumes de dados, independentemente do tipo de aplicação" é falsa porque a escolha do banco de dados depende das características da aplicação — como consistência, transações, relacionamentos e padrão de acesso — e não apenas do volume. Não existe uma tecnologia universalmente superior; cada modelo (relacional ou NoSQL) tem pontos fortes e fracos que o tornam mais ou menos adequado a cada cenário.

A afirmação carrega dois erros conceituais que merecem destaque. O primeiro é o uso da palavra "sempre", que transforma uma recomendação técnica em uma regra absoluta — e regras absolutas raramente sobrevivem ao contato com a diversidade de requisitos de sistemas reais. O segundo é a ideia de que "grandes volumes de dados" é o único critério relevante, ignorando que a escolha do banco é uma decisão de arquitetura que envolve trade-offs entre consistência, disponibilidade, tolerância a partição, latência, modelo de dados e até custo operacional.

Para entender por que a afirmação está errada, é preciso compreender o que diferencia os bancos NoSQL dos relacionais. Os bancos relacionais (como PostgreSQL, MySQL e Oracle) organizam os dados em tabelas com esquema rígido e garantem as propriedades ACID (Atomicidade, Consistência, Isolamento e Durabilidade), o que os torna ideais para aplicações que exigem forte consistência e transações complexas — como sistemas bancários, ERPs e sistemas de folha de pagamento. Já os bancos NoSQL (como MongoDB, Cassandra e Redis) abandonam o modelo relacional em favor de modelos mais flexíveis — documentos, chave-valor, colunas ou grafos — e frequentemente relaxam a consistência em favor de disponibilidade e escalabilidade horizontal, seguindo o teorema CAP.

O teorema CAP (Consistência, Disponibilidade e Tolerância a Partição) é central para entender essa discussão. Ele afirma que, em um sistema distribuído, é impossível garantir simultaneamente consistência forte, disponibilidade e tolerância a partição de rede. Como partições de rede são inevitáveis em sistemas distribuídos, a escolha real é entre consistência e disponibilidade. Bancos NoSQL frequentemente optam por disponibilidade (eventual consistency), enquanto bancos relacionais priorizam consistência. Isso significa que, para uma aplicação que não pode tolerar leituras desatualizadas — como um sistema de reservas de passagens aéreas ou um sistema de controle de estoque em tempo real —, um banco NoSQL pode ser uma escolha ruim, mesmo com grandes volumes de dados.

Um exemplo concreto ajuda a fixar: imagine uma aplicação bancária que processa milhões de transações por dia. O volume de dados é enorme, mas a aplicação exige consistência imediata — se um cliente transfere dinheiro, o saldo deve refletir a mudança instantaneamente para qualquer consulta. Um banco NoSQL com consistência eventual poderia retornar um saldo desatualizado, causando erros graves. Nesse caso, um banco relacional com suporte a transações ACID é a escolha correta, apesar do volume. Por outro lado, uma rede social que armazena bilhões de posts e precisa de alta disponibilidade e escalabilidade pode se beneficiar de um banco NoSQL, pois a consistência eventual é aceitável para a maioria das operações.

A pegadinha da banca está em explorar a generalização indevida: o candidato que sabe que NoSQL é bom para grandes volumes pode marcar "certo" sem perceber que a afirmação ignora o tipo de aplicação. A banca não está dizendo que NoSQL é ruim — está dizendo que ele não é "sempre" a melhor escolha, e essa palavra é a chave da questão. A escolha do banco de dados é uma decisão de engenharia que deve considerar o perfil da aplicação, e não uma preferência dogmática.

Guarde o critério decisivo: a escolha entre banco relacional e NoSQL depende do equilíbrio entre consistência, disponibilidade, modelo de dados e padrão de acesso — não apenas do volume. É exatamente essa fronteira que a questão explora.

Alternativa C — ❌ Incorreta

A alternativa afirma que bancos NoSQL são "sempre a melhor escolha para grandes volumes de dados, independentemente do tipo de aplicação". O erro está na generalização indevida: a palavra "sempre" e a expressão "independentemente do tipo de aplicação" tornam a afirmação falsa. A escolha do banco de dados depende de múltiplos fatores, incluindo a necessidade de consistência, transações ACID, relacionamentos complexos e padrão de acesso. Para aplicações que exigem forte consistência e transações, como sistemas bancários, um banco relacional é frequentemente a melhor escolha, mesmo com grandes volumes de dados. Além disso, o teorema CAP mostra que não existe uma solução universal: cada sistema distribuído precisa fazer trade-offs entre consistência, disponibilidade e tolerância a partição.

Alternativa E — ✅ Correta ⟵ GABARITO

A alternativa está correta porque a afirmação do enunciado é falsa. Bancos NoSQL não são "sempre" a melhor escolha para grandes volumes de dados, pois a adequação depende do tipo de aplicação. A escolha do banco de dados deve considerar requisitos como consistência, transações, modelo de dados e padrão de acesso. Para aplicações que exigem forte consistência e transações ACID, bancos relacionais são mais adequados, mesmo com grandes volumes. A palavra "sempre" é o termo que torna a afirmação incorreta, pois generaliza uma recomendação que, na prática, é condicional.

Gabarito: letra E (ERRADO).