Esse é um post é um pouco diferente dos outros, pois esse não é nada técnico e mão na massa, e sim com o intuito de conscientização.

Infelizmente muitas empresas não compreendem a importância de ter DBA trabalhando em conjunto com o time de desenvolvimento em todas as etapas do projeto, o DBA ainda é visto como a pessoa que será acionada apenas quando problemas no ambiente de produção acontecerem e com SLA nível 0. Mas mal sabem que o trabalho do DBA é para que isso nunca aconteça.

Então qual a importância e as suas atribuições de envolver o DBA em um projeto desde o inicio?

Bem, o DBA tem dois papeis fundamentais no processo de desenvolvimento de um projeto, que podem ser ou não desempenhados pela mesma pessoa(normalmente é, se você está em uma empresa que não é, pode ter certeza que já é um privilegiado).
Apesar que mais recentemente apareceram(ou ficaram mais famosas) várias nomenclaturas para as atividades do DBA(DBA, DBO, DA, DS, etc…), na essência o trabalho do DBA vai se dividir entre Administração do servidores de banco de dados e Desenvolvimento de banco de dados, que é o DBA que vai trabalhar mais com o foco na modelagem e desenvolvimento de queries.

O trabalho do DBA deve iniciar no momento zero de cada projeto, pois a definição de qual banco de dados será utilizado pode ser fundamental para um sistema saudável no futuro, por exemplo, usar um banco de dados NoSQL para um sistema que precisa de características relacionais já é um baita tiro no pé e quando ele estiver em produção as chances de problemas de todos os tipos, sem contar que com esse cenário a responsabilidade dos dados passa para a programação, e o banco de dados serve apenas como um lugar que armazena os dados.

Com o banco de dados(SGDB) definido, inicia o trabalho de modelagem de dado. Nesse momento será desenhado o esqueleto de sustentação de um sistema, pois por mais que venham a existir inúmeras regras de negócio, a execução, validação e bom funcionamento dessas regras de negócio será muito mais simples com uma modelagem de dados bem feita.
Deve existir uma harmonia entre  a modelagem de dados e o diagrama de classes, eles devem ser construídos juntos. Uma coisa que me me deixa triste é quando o diagrama de classes está pronto, todos os requisitos levantados, os programadores iniciando a escrever as primeiras linhas de código e nesse momento o DBA é envolvido para dar uma olhadinha nas tabelas que foram criadas, muitas vezes sem regras de nomenclatura, sem uma correta definição dos tipos de dados, engines, posicionamento de colunas, chaves estrangeiras, índices, dimensionamento do hardware, etc…
Sim, se o DBA for envolvido desde o inicio, na versão inicial da modelagem tudo isso ja vai estar bem encaminhado, claro que irá ter alterações, mas em menor quantidade e com menos impacto possível para o desenvolvimento. E como já dizia o É o Tcham “Pau que nasce torto nunca se endireita”. Isso significa que depois que o desenvolvimento já iniciou qualquer alteração que visa a saúde do banco de dados fica de difícil implementação e cara e normalmente não é feita, ja que na maioria das vezes arrumar esses problemas de estruturas e conceitos é o mesmo que reescrever parte do sistema.

Ok, entendi, então o DBA modela o banco e pronto? tudo vai ser um livro com final feliz?

Não!
Mas isso vai contribuir para que os problemas não aconteçam, ou se acontecer eles tenham o menor impacto possível.

Em paralelo ou depois com a modelagem(depende de quantos DBAs tem no projeto) inicia a fase de planejar o ambiente de banco de dados, configurar, “tunar”, ajustar monitoramento, políticas de backup e restore, redundância, failover, etc…

Mas não para por aqui, tem toda a parte de segurança de acesso aos dados, segurança dos dados, auditoria, é um trabalho que inicia no momento 0 e nuca mais termina, o acompanhamento do banco de dados será até o fim da vida do sistema.

O DBA não faz parte do projeto apenas para resolver os problemas de lentidão apresentados, ele está lá para evitar que esses problemas aconteçam e quanto menos problemas, mais horas de sono para todos e credibilidade o sistema vai ter.

Então nada de colocar na cabeça que a primeira coisa que o DBA aprende é ser chato, acontece que que assim como o time de desenvolvimento o DBA tem muitas tarefas e responsabilidades e muito desse trabalho vai sim entrar em conflito com o desenvolvimento mas sempre pelo bem do projeto. Mas a segunda coisa que o DBA aprende é ser chato sim, pois sem ser chato dificilmente as regras e necessidades do banco de dados sejam atendidas, e por último o DBA aprende que as coisas tem que ser feitas da forma correta já no inicio, pois depois as melhorias viram lenda.

Então cuidado para o barato não sair caro.

 

Post Navigation