Banco de Dados no Currículo: Como Nomear SGBD, Modelagem e Uso

No currículo, banco de dados quase nunca aparece como termo que pesa, porque a expressão cabe em qualquer vaga de tecnologia e em muitas outras. O que diferencia uma linha forte é o nome do sistema gerenciador e o trabalho feito com ele: o modelo projetado, as consultas afinadas, a migração conferida ou a cópia de segurança que alguém restaurou de fato. Este guia mostra como nomear o SGBD, descrever cada tipo de trabalho e separar quem administra o banco de quem apenas usa um sistema que roda sobre ele.

Nomeie o sistema gerenciador, não só a categoria

Escreva o SGBD que você usou, com a versão quando souber, e não apenas banco de dados. A categoria não diz nada sobre o seu trabalho, e o recrutador procura pelo nome do motor que a equipe usa. Estes são os nomes que mais aparecem em vagas, com um sentido para cada um:

• PostgreSQL. Relacional e de código aberto, comum em sistemas novos e em operações de dados. Se você escreveu consultas, modelou tabelas ou ajustou índices nele, o nome vale a linha.
• MySQL e MariaDB. Relacionais e muito presentes em sistemas web. Costumam aparecer em vagas de desenvolvimento e de suporte a aplicações, e a diferença entre eles raramente importa para o currículo.
• SQL Server. Relacional da Microsoft, frequente em empresas com ambiente Windows e em sistemas corporativos antigos. Se você fez rotinas de manutenção ou planos de backup nele, diga isso.
• Oracle. Relacional comercial, usado com frequência em grandes organizações. A experiência com ele costuma ser específica de uma instalação, e a linha ganha força quando descreve o sistema atendido.
• MongoDB. Orientado a documentos, não a tabelas. Tem uso próprio e deve ser citado como tal, sem ser tratado como se fosse relacional.

Modelagem: escreva o que você projetou, não só o que consultou

Modelar um banco é decidir quais tabelas existem, como elas se relacionam e quais regras impedem dados inconsistentes, como um mesmo horário reservado duas vezes. Esse trabalho aparece pouco nas linhas de currículo, e é justamente por isso que uma linha bem escrita se destaca.

Antes: Experiência com banco de dados relacional.

Depois: Projetei o modelo de dados de um sistema de agendamento com dezoito tabelas, chaves estrangeiras e uma regra de unicidade que impede dois agendamentos no mesmo horário para o mesmo profissional.

A segunda versão diz quantas partes existem e qual problema a regra resolveu. Se você não projetou o modelo do zero, mas evoluiu um existente, diga isso: acrescentei três tabelas e uma regra de validação num modelo que já estava em uso. Mexer em um modelo vivo é um trabalho diferente, e quem contrata sabe disso.

Afinação: a linha certa fala do banco inteiro, não de uma consulta

Afinar um banco é descobrir quais consultas pesam, quais índices faltam e quais podem sair sem prejuízo. A otimização de uma consulta isolada é assunto do guia de SQL no currículo. Aqui, o trabalho é outro: olhar o conjunto e decidir onde mexer.

Antes: Otimização de banco de dados para melhor desempenho.

Depois: Identifiquei no log do servidor as cinco consultas que mais consumiam tempo do sistema de pedidos. Criei dois índices compostos e atualizei as estatísticas do banco, e o tempo médio do relatório diário caiu de vários minutos para menos de um.

Se você não tem o log ou a medida, descreva a ação e não o resultado: ajudei a revisar índices de um banco de pedidos e acompanhei o efeito no relatório. O ganho inventado é o que a entrevista desfaz mais rápido.

Migração conferida vale mais do que migração concluída

Trocar de banco, ou atualizar a versão de um banco em produção, é uma tarefa em que a parte perigosa é a conferência. Copiar os dados é a parte fácil. A linha forte diz o que foi comparado depois da cópia e o que estava pronto para voltar atrás caso algo desse errado.

• Conferência de volume. Compare a quantidade de registros de cada tabela entre origem e destino. Uma diferença pequena já é um aviso.
• Conferência de conteúdo. Escolha uma amostra de registros com regras de negócio, como cálculos e datas, e confira valor por valor.
• Plano de volta. Mantenha a origem disponível e escreva até quando ela ficou de reserva. Quem migra sem plano de volta não deve descrever a migração como segura.

Uma linha como “migrei o banco do sistema de cadastro, com conferência de contagem por tabela e amostra de cálculos financeiros” já diz o tamanho do trabalho sem precisar de adjetivo. Não é preciso citar as duas pontas da migração se você só fez uma delas, mas diga qual.

Se a migração é de um sistema de recrutamento, o texto sobre como migrar de ATS sem perder candidatos trata da mesma conferência, aplicada aos dados de candidatos.

Cópia de segurança só existe depois de restaurada

Backup é a rotina mais citada e a menos verificada. Um currículo que diz “realizo backups diários” deixa a pergunta óbvia: você já restaurou um deles? Quem trabalha com banco sabe que uma cópia que nunca foi restaurada é uma esperança, não uma garantia.

Antes: Realização de backups e rotinas de manutenção.

Depois: Configurei a cópia diária do PostgreSQL com retenção de trinta dias e faço, uma vez por mês, a restauração em ambiente de teste para confirmar que a cópia abre e tem os dados.

Se você configurou a rotina e não testou a restauração, escreva a configuração e não a garantia. E se o acesso ao banco também faz parte do seu trabalho, como criar perfis e revogar permissões, esse controle entra como outra linha, com o número de perfis gerenciados, quando couber.

Quem administra, quem modela e quem só usa são três linhas diferentes

Um recrutador separa essas três funções, e o currículo precisa fazer o mesmo. Quem administra mexe no servidor, nas permissões e nas cópias. Quem modela projeta tabelas e regras. Quem usa cadastra, consulta e corrige registros por um sistema. Escreva a função que foi a sua.

Em áreas fora da tecnologia, como saúde, educação e engenharia, o banco costuma ser um sistema de gestão ou uma planilha grande. Nesse caso, a linha honesta descreve a tarefa de dados: cadastro, conferência, correção e extração de relatório. O nome do motor só entra se você souber qual é. Para um caso de tecnologia que lida com dados de forma mais ampla, o texto sobre o currículo de engenheiro de dados explica como organizar essas linhas junto com o restante da experiência. Se o seu trabalho com dados chega até a análise, o guia de estatística no currículo mostra como escrever a pergunta, a amostra e a ferramenta.

O que colocar antes de enviar

A regra deste guia é simples: nomeie o SGBD, descreva a função que você exerceu com o banco e, quando existir, mostre o que foi conferido, testado ou restaurado. Uma linha sem essas partes soa como um termo que todo currículo de tecnologia usa. Se a vaga pede também consultas, o guia de SQL no currículo ajuda a escrever esse nível. Antes de enviar, copie da vaga os termos de banco e veja se cada um tem uma frase de experiência que o prove. A análise gratuita do AjustaCV compara o seu currículo com o texto da vaga que você colar, sem cadastro, e mostra quais termos já aparecem e quais faltam. Para comparar os termos de desenvolvimento que costumam acompanhar o banco, veja as palavras-chave de desenvolvedor full stack.

Perguntas frequentes