Introduzindo SQL

O que é SQL?

SQL (Structured Query Language) é uma linguagem de programação utilizada para gerenciar e manipular dados armazenados em sistemas de gerenciamento de bancos de dados relacionais (RDBMS). Ela permite recuperar, inserir, atualizar e excluir dados, bem como definir esquemas de banco de dados e controlar o acesso aos dados. A compreensão básica de SQL é fundamental para interagir com praticamente qualquer banco de dados.

Bancos de dados Relacionais

Em 1970, o cientista da computação Edgar F. Codd publicou um artigo que mudaria para sempre a forma como armazenamos e consultamos dados. Nele, propunha organizar informações em estruturas tabulares — linhas e colunas — conectadas entre si por meio de relacionamentos lógicos. Nascia ali o modelo relacional, base de praticamente todo sistema de software corporativo que conhecemos hoje.

Um banco de dados relacional armazena dados em tabelas. Cada tabela representa uma entidade do mundo real: clientes, pedidos, produtos. Cada linha é um registro individual, e cada coluna descreve um atributo desse registro. O que torna o modelo poderoso não é apenas a organização em tabelas, mas a capacidade de relacioná-las — uma tabela de pedidos pode referenciar a tabela de clientes por meio de uma chave estrangeira, evitando duplicação e garantindo que os dados permaneçam consistentes.

Essa consistência é garantida por um conjunto de propriedades conhecido pela sigla ACID: as operações são atômicas (ou tudo acontece, ou nada acontece), o banco sempre transita entre estados válidos, transações concorrentes não interferem entre si, e dados confirmados persistem mesmo diante de falhas. São essas garantias que tornam os SGBDRs a escolha natural para sistemas financeiros, hospitalares e qualquer domínio onde a integridade dos dados não é negociável.

PostgreSQL, MySQL, Oracle Database e SQL Server são os representantes mais conhecidos dessa família. Cada um com suas particularidades, mas todos falando a mesma língua: o SQL.

Benefícios e Limitações dos SGBDRs

Por décadas, o modelo relacional foi sinônimo de banco de dados. E com razão: ele resolve de forma elegante um problema difícil, que é manter grandes volumes de dados organizados, íntegros e acessíveis de forma eficiente.

A linguagem SQL, padronizada e amplamente dominada pela indústria, permite expressar consultas complexas com poucas linhas. Um JOIN entre três tabelas que retorna exatamente os dados necessários, filtrados e ordenados, é algo que o modelo relacional faz com naturalidade. Somado a décadas de otimização dos engines, ferramentas maduras de administração e uma comunidade enorme, o SGBDR é uma das tecnologias mais confiáveis que existem.

Mas toda escolha tem um custo. O modelo relacional exige que o esquema seja definido antes de armazenar os dados — e alterar esse esquema em produção pode ser uma operação delicada e cara. Em sistemas que evoluem rápido, ou cujos dados não têm forma bem definida, essa rigidez vira um obstáculo.

Há também uma questão de escala. SGBDRs foram projetados para crescer verticalmente: quando o banco fica lento, você coloca mais memória, mais CPU, um disco mais rápido. Essa estratégia tem um limite físico e financeiro. Distribuir um banco relacional entre dezenas de servidores — escala horizontal — é tecnicamente possível, mas complexo, e vai contra a natureza do modelo. Para aplicações que precisam atender centenas de milhões de usuários com latência mínima, essa limitação se torna crítica.

SQL vs. NoSQL

À medida que a internet cresceu, ficou evidente que o modelo relacional não era a resposta para todos os problemas. O ponto de virada aconteceu nos anos 2000, quando empresas como Google e Amazon começaram a enfrentar volumes de dados que nenhum SGBDR tradicional suportava adequadamente. Em 2006, o Google publicou o paper do Bigtable. Em 2007, a Amazon publicou o paper do Dynamo. Em 2008, o Facebook abriu o código do Cassandra, desenvolvido internamente para gerenciar a caixa de entrada de seus usuários. O termo "NoSQL" foi popularizado em uma meetup em San Francisco, em junho de 2009 — e a partir daí o movimento tomou forma.

A motivação era clara: estima-se que cerca de 80% de todos os dados gerados hoje são não estruturados — mensagens, imagens, logs, dados de sensores, eventos de clique. Esse tipo de dado não cabe naturalmente em linhas e colunas de uma tabela relacional. Surgiu então o NoSQL, que mais do que uma negação do SQL, significa "Not Only SQL": uma expansão do repertório de soluções disponíveis.

NoSQL não é um único tipo de banco de dados, mas uma família de abordagens. Os bancos de documentos, como MongoDB, armazenam dados em formato JSON sem esquema fixo — ideais para catálogos e perfis de usuário. Os bancos de chave-valor, como Redis, operam como dicionários extremamente rápidos, perfeitos para cache e sessões. Os bancos de coluna larga, como Cassandra, foram construídos para escalar horizontalmente: o Netflix, por exemplo, usa Cassandra para processar mais de 1 trilhão de operações por dia. E os bancos de grafo, como Neo4j, modelam entidades e relacionamentos de forma nativa — a base de qualquer sistema de recomendação ou rede social.

A grande concessão do NoSQL está na consistência. O teorema CAP, formulado por Eric Brewer em 2000, estabelece que um sistema distribuído não pode garantir simultaneamente consistência, disponibilidade e tolerância a partições de rede — é preciso abrir mão de um. A maioria dos sistemas NoSQL escolhe disponibilidade e tolerância a partições, adotando o modelo BASE: a consistência é eventual, podendo levar alguns milissegundos até que todos os nós do cluster reflitam o novo valor. Para uma rede social, isso é aceitável. Para um sistema bancário, não.

A escolha entre SQL e NoSQL, portanto, não é uma questão de qual é melhor — é de qual serve melhor ao problema. O Stack Overflow Developer Survey de 2023 mostra PostgreSQL como banco de dados mais utilizado no mundo, com 45% dos desenvolvedores, enquanto MongoDB lidera entre os NoSQL com 28%. Esses números dizem algo importante: os dois modelos coexistem, e cada um domina onde faz sentido dominar.

Na prática, sistemas modernos raramente escolhem apenas um lado. É comum usar PostgreSQL para os dados transacionais do negócio, Redis para cache de sessões e MongoDB para conteúdo dinâmico. A Amazon, que concluiu em 2019 a migração completa de seus sistemas internos para fora do Oracle — economizando cerca de US$ 1 bilhão por ano —, hoje oferece mais de quinze tipos diferentes de banco de dados na AWS. Cada ferramenta, no lugar onde ela brilha.

Aprendendo os Fundamentos Técnicos

Antes de escrever consultas complexas, é preciso dominar o vocabulário básico do SQL. Esses quatro elementos: palavras-chave, tipos de dados, operadores e sintaxe, são a gramática da linguagem. Entendê-los bem é o que separa quem decora comandos de quem realmente entende o que está escrevendo.