Nesta segunda-feira mostrei que o mapeamento objeto relacional de uma aplicação inteira pode ser feito em 60 linhas de código e deixei no ar a pergunta que dá nome a este post:

– O DBA morreu?

Vou respondê-la agora:

– Não. Não morreu. Nem vai morrer. Aliás, é o contrário.

Porque não? Porque ele não morreu se agora o banco virou um mero repositório de dados? Respondo: não morreu porque o banco não é um mero repositório de dados. Apesar de hoje termos ORMs capazes de fazer todo o mapeamento automaticamente (ou mesmo que tenhamos que fazê-lo manualmente para depois o ORM gerar um banco de dados) isso só significa que temos produtividade neste contato com o banco. É o DBA, o especialista em banco de dados, quem vai ajudar a preparar o banco para uma aplicação, o que vai muito além de gerar algumas tabelas.

O que isso significa? Devemos então ignorar o automapeamento? Ou o mapeamento fluente? Temos que abandonar os ORMs?

Não, claro que não. Na maioria da aplicações (na minha experiência – e isso varia), em torno de 50% das suas operações de entrada e saída de dados são simples CRUDs, sem muita complexidade. É comum também que estas mesmas operações sejam pouco usadas pelos usuários, já que as telas que trazem valor para o negócio não são simples CRUDs, ou o sistema sequer seria necessário. É nestas telas complexas que nosso esforço deve se concentrar. E é nas telas de CRUD simples que o automapeamento e os ORMs realmente ajudam. No resto podemos usar um mapeamento manual, ou até eliminar o ORM por completo. Se precisamos de performance, se temos que espremer cada milisegundo, por exemplo, talvez um ORM não seja a solução ideal. Nesse cenário podemos isolar as partes da aplicação que tem essas características, e não usar um ORM. No resto, usamos um ORM com mapeamento automático. Ganhamos tempo e dinheiro para quem está pagando pela aplicação.

Além disso, um DBA sempre é importante no final das iterações do projeto, já que é lá que você vai precisar testar e otimizar a performance da aplicação, além de verificar sua adequação aos diversos padrões do projeto. Então, no final da iteração, você examina o modelo gerado pelo seu ORM junto do DBA e confirma se ele quer mudar alguma coisa, acrescentar índices, mudar colunas, tabelas, etc. Depois de pegar esse feedback o banco é refatorado, junto com o mapeamento, tudo é revisado, e a iteração segue para sua conclusão. O DBA atua confirmando se os desenvolvedores, que em geral não especialistas em banco de dados, não estão cometendo nenhum absurdo. É bom que ele faça isso, já que é ele quem vai conviver com o banco de dados depois.

Depois que paramos para pensar, parece óbvio, não é? No mundo de hoje precisamos de pessoas cada vez mais especializadas. Precisamos de especialistas em algorítmos, de conhecedores de paradigmas de linguagens diferentes, de arquitetos, entre outros tipos de especialistas, e os especialistas de banco de dados claramente não poderiam ficar de fora. E eles vão ficar mais importantes ainda, conforme as tecnologias de armazenagem evoluem. O que pode acontecer é que talvez precisemos de menos DBAs para sustentar as aplicações (algo que tem acontecido), mas eu não arriscaria minha vida nisso.

Giovanni Bassi

Arquiteto e desenvolvedor, agilista, escalador, provocador. É fundador e CSA da Lambda3. Programa porque gosta. Acredita que pessoas autogerenciadas funcionam melhor e por acreditar que heterarquia é mais eficiente que hierarquia. Foi reconhecido Microsoft MVP há mais de dez anos, dos mais de vinte que atua no mercado. Já palestrou sobre .NET, Rust, microsserviços, JavaScript, TypeScript, Ruby, Node.js, Frontend e Backend, Agile, etc, no Brasil, e no exterior. Liderou grupos de usuários em assuntos como arquitetura de software, Docker, e .NET.