Resolvi fazer eu mesmo uma réplica ao post anterior antes que os desenvolvedores comecem a me jogar pedras…
- Se você não quer que as pessoas fiquem ligando para você o tempo todo para saber se o banco de dados está no ar, disponibilize uma ferramenta (de preferência web) para que eles possam checar o status do servidor.
- Ajude seus desenvolvedores a homologar a solução. Facilite o teste com dados reais ou utilize ferramentas para injetar dados na aplicação. Crie métricas para testes e discuta elas com seus desenvolvedores antes de homologar a solução.
- Procure conhecer a regra de negócios da aplicação que está sendo desenvolvida. Procure conhecer o modelo de dados da aplicação durante o desenvolvimento da mesma. Se você encontrou um problema grave, não reclame apenas, mostre alternativas e se possível faça testes comparativos para mostrar a diferença de performance das diferentes abordagens.
- Sempre que você puder consertar um problema de desempenho alterando o modelo físico sem alterar o modelo lógico, faça-o. Existem muitas ferramentas disponíveis para um DBA experiente contornar alguns problemas.
- Desenvolvedores vivem num mundo dinâmico com exigências que mudam o tempo todo. Procure entender a dinâmica dos negócios da empresa. Estabeleça regras mínimas para serem seguidas pelos desenvolvedores e saiba quebra-las em momentos de crise. Se precisar quebrar uma regra, dê um prazo para o desenvolvedor se adequar depois que o sistema entrou em produção. Se você nunca acompanhar o rítimo dos negócios da empresa, pode haver um momento que não haja mais empresa com dados para cuidar!
- Ser cauteloso não pode significar ser covarde. Um dia você vai ter de migrar de versão do seu SGDB. Seus desenvolvedores esperam por uma série de funcionalidades disponíveis nas novas versões. Considere que 2 anos é um tempo razoável para uma nova versão se estabilizar. Ao invés de se opor às mudanças, crie um calendário de testes bastante generoso.
- Não fazer alterações direto na base de produção não significa que não é possível realizar alterações num prazo mais curto. Se a alteração for urgente, dê prioridade para a alteração e peça ajuda do desenvolvedor para os testes. Se isto for comum, crie alternativas para agilizar os testes como ter bases de dados com dados atualizados com uma certa frequência.
- Não se proponha a colocar parte da inteligência da aplicação dentro do banco de dados se você não tiver fôlego para manter isso. Saiba balancear bem isso e não torne a aplicação totalmente dependente de um fornecedor de SGDB desnecessariamente.
- Procure conhecer um pouco da linguagem de programação utilizada pela aplicação. Foque o seu estudo na forma como a linguagem se conecta no banco de dados e nas funções adjacentes. Isto ajudará muito no processo de orientação ao desenvolvedor.
- Crie algum tipo de documentação para orientar os desenvolvedores a criarem aplicações que não criem problemas sérios de performance. Crie metas de desempenho como tempo máximo para uma consulta, regras para transações em lote, etc. Dê pleno suporte para aqueles que se empenharem em seguir as suas recomendações.
- Não espere que o desenvolvedor crie toda a documentação que você precisará. Você deve no mínimo documentar os requisitos de performance, atributos do modelo físico e testes comparativos de performance.
- Procure não se portar apenas como alguém que presta suporte ao desenvolvedor e sim como alguém que faz parte da equipe de desenvolvimento. Dê sugestões, se comprometa com o projeto e com o core business da empresa.
