Extensão — Além do SQLite: PostgreSQL, MySQL e MongoDB

No artigo Extensão — Páginas Dinâmicas: HTML Gerado com Templates unimos banco, servidor e templates numa aplicação web completa, usando o SQLite como nossa persistência. O SQLite foi a escolha ideal para aprender — embutido, simples, num arquivo. Mas o Extensão mapeou outros bancos que dominam o mundo real: os servidores de banco de dados, como PostgreSQL, MySQL e MongoDB. Hoje damos o panorama deles. Não vou repetir código de integração para cada um — seria redundante, porque a lição mais importante é justamente esta: os princípios do curso se aplicam a todos eles de forma uniforme. RAII envolve suas conexões, exceções ou expected tratam suas falhas, a STL organiza seus resultados. Conhecer as diferenças entre eles (para escolher bem) e a semelhança de como o C++ os aborda (RAII em toda parte) é o que completa seu mapa da persistência. Este é um artigo de panorama e critério, não de mais um exemplo repetido.

Embutido versus servidor: a distinção fundamental

A diferença mais importante entre o SQLite e os outros três é arquitetural, e já a tocamos no Extensão. O SQLite é embutido: roda dentro do seu processo, guarda tudo num arquivo local, sem servidor separado. Os outros — PostgreSQL, MySQL, MongoDB — são servidores: processos (frequentemente em máquinas dedicadas) aos quais sua aplicação se conecta pela rede. Essa diferença tem consequências profundas. Um banco servidor atende múltiplos clientes simultâneos, gerencia usuários e permissões, escala para volumes enormes de dados e requisições, e permite que muitas aplicações compartilhem os mesmos dados. Em troca, exige instalação, configuração, administração e uma conexão de rede. Regra prática: use embutido (SQLite) para dados locais de uma única aplicação; use servidor quando múltiplas aplicações ou usuários precisam compartilhar dados, ou quando o volume exige uma infraestrutura dedicada. A escolha é arquitetural, não de preferência.

Os três servidores e quando escolher cada um

Cada banco servidor tem um perfil, e escolher bem depende do seu problema. Vale o mapa com critério honesto:

O PostgreSQL é um banco relacional (dados em tabelas com relações, consultados com SQL) conhecido por robustez, conformidade rigorosa com padrões, e um conjunto riquíssimo de recursos avançados (tipos customizados, consultas sofisticadas, extensibilidade). É frequentemente a escolha padrão para aplicações sérias que precisam de um banco relacional confiável. Em C++, acessa-se tipicamente via a biblioteca libpqxx. Escolha-o quando quer um banco relacional completo, correto e poderoso, e a robustez importa mais que a simplicidade.

O MySQL (e seu fork MariaDB) é outro banco relacional servidor, historicamente popular por ser rápido, simples de começar, e onipresente em hospedagem web. É uma escolha sólida e madura, com vasta comunidade. Em C++, usa-se o MySQL Connector/C++. Escolha-o quando quer um relacional bem-estabelecido, especialmente em contextos onde ele já é o padrão (muitas stacks web tradicionais), ou por familiaridade da equipe.

O MongoDB é fundamentalmente diferente: é um banco de documentos (NoSQL), que guarda dados como documentos flexíveis semelhantes a JSON, não em tabelas rígidas. Não usa SQL, e não força um esquema fixo — cada documento pode ter estrutura diferente. Em C++, acessa-se via o driver mongocxx. Escolha-o quando seus dados são naturalmente hierárquicos ou variáveis (não se encaixam bem em tabelas), quando você precisa de flexibilidade de esquema, ou para certos padrões de escala horizontal. A honestidade: a escolha entre relacional (Postgre/MySQL) e documentos (Mongo) é uma decisão de arquitetura de dados com trade-offs reais — relacionais brilham com dados estruturados e relações complexas e garantias de consistência fortes; documentos brilham com flexibilidade e dados aninhados. Não há vencedor universal; há o certo para o seu modelo de dados.

A semelhança que importa: RAII em toda parte

Agora a lição central, e a razão de eu não repetir código para cada um. Apesar de suas diferenças, todos esses bancos apresentam, do ponto de vista do C++, o mesmo padrão de recurso — e você já sabe domá-lo. Cada um tem uma conexão que se abre e deve fechar-se: isso é RAII (Fase 2), envolvido numa classe que abre no construtor e fecha no destrutor, exatamente como fizemos com o BancoSQLite no Extensão. Cada um pode falhar (conexão recusada, consulta inválida, servidor fora do ar): isso é tratamento de erros (Fase 6), com exceções ou expected transformando falhas em algo que seu código trata com clareza. Cada um devolve resultados — linhas ou documentos: isso é a STL (Fase 4), com os resultados armazenados em vector, map ou tipos apropriados. Conceitualmente, uma classe de conexão para qualquer um deles tem a mesma forma:

// O PADRÃO é o mesmo para todos os bancos — só muda a API interna.
class ConexaoBanco {
public:
    ConexaoBanco(const std::string& parametros) {
        // Abre a conexão usando a API específica (libpqxx, mysqlcppconn, mongocxx...).
        // Lança se falhar. — Fase 6
        conectar(parametros);
    }
    ~ConexaoBanco() {
        // Fecha a conexão automaticamente. — Fase 2 (RAII)
        desconectar();
    }
    ConexaoBanco(const ConexaoBanco&) = delete;   // dono único — Fase 2/8

    // Executa e devolve resultados numa estrutura da STL. — Fase 4
    std::vector<Registro> consultar(const std::string& query);
private:
    /* handle da conexão específico do banco */
};

O interior de conectar, desconectar e consultar difere entre PostgreSQL, MySQL e MongoDB — cada um usa sua biblioteca. Mas a estrutura — RAII envolvendo a conexão, exceções para falhas, STL para resultados — é idêntica. É por isso que dominar os princípios do curso vale mais que decorar a API de cada banco: aprenda o padrão uma vez, aplique-o a qualquer banco. Quando você precisar do PostgreSQL amanhã, não estará aprendendo do zero — estará aplicando o RAII que já domina a uma nova API. Os conceitos transcendem as bibliotecas específicas.

A honestidade sobre este panorama e a integração

Prometo a franqueza final sobre persistência. Não mostrei código completo de integração para cada banco por duas razões honestas. Primeira, seria repetitivo: como acabei de mostrar, o padrão RAII é o mesmo, e ver três versões quase idênticas ensinaria pouco além do que o SQLite já ensinou. Segunda, e importante, integrar esses bancos servidor é significativamente mais trabalhoso que o SQLite — envolve instalar e rodar o servidor, configurar credenciais e rede, e integrar bibliotecas mais pesadas via CMake (libpqxx, mysqlcppconn, mongocxx têm suas próprias dependências). Esse trabalho de infraestrutura, embora real e importante, é específico de cada biblioteca e ambiente, muda com o tempo, e distrairia dos conceitos — é o tipo de coisa que se resolve consultando a documentação atual de cada driver quando você for usá-lo. O que fica desta aula, e que é o durável, é o critério (qual banco para qual problema) e o padrão (RAII, erros, STL aplicados uniformemente). Quando você integrar um desses na prática, seguirá a documentação do driver para os detalhes de API, mas a estrutura do seu código C++ já a conhece. É a diferença entre saber a receita e saber cozinhar.

Os bancos mudam de API, não de forma: abrir no construtor, fechar no destrutor, proibir cópia, permitir movimento — a classe de conexão do PostgreSQL e a do MongoDB têm o mesmo esqueleto, ainda que nenhuma linha coincida. A escolha entre eles é de requisito: consistência forte e relações complexas puxam para o relacional, campos que variam de registro para registro puxam para documentos, e rodar sem servidor puxa para o embutido.

Fontes e leituras recomendadas

• pqxx.org: a documentação da libpqxx, o conector C++ do PostgreSQL.
• dev.mysql.com/doc/connector-cpp/en: a documentação do MySQL Connector/C++.
• mongocxx.org: o driver C++ do MongoDB, com guias de uso.
• "Relational vs NoSQL databases": comparações (na documentação do PostgreSQL e do MongoDB) sobre quando escolher cada modelo.
• use-the-index-luke.com: um recurso excelente sobre SQL e indexação, aplicável a PostgreSQL e MySQL.

Exercícios

Exercício 1

Explique, com suas palavras, a diferença arquitetural entre um banco embutido (SQLite) e um banco servidor (PostgreSQL). Para um aplicativo de celular que guarda notas localmente, qual escolher e por quê?

Exercício 2

Distinga um banco relacional (PostgreSQL, MySQL) de um banco de documentos (MongoDB). Dê um exemplo de dados que se encaixam bem no modelo relacional e outro que se encaixa melhor no modelo de documentos.

Exercício 3

A aula afirma que "o padrão RAII é o mesmo para todos os bancos". Explique concretamente como uma classe de conexão para PostgreSQL e uma para MongoDB, apesar de usarem bibliotecas totalmente diferentes, compartilhariam a mesma estrutura RAII.

Exercício 4

Você está projetando um sistema que precisa: (a) guardar transações financeiras com garantias fortes de consistência e relações complexas entre contas; (b) guardar perfis de usuário com campos que variam muito entre usuários. Que tipo de banco escolheria para cada caso e por quê?

Exercício 5

Discuta por que dominar os princípios do curso (RAII, tratamento de erros, STL) é mais valioso que decorar a API de um banco específico. Como isso se aplica quando você precisa migrar uma aplicação de um banco para outro?