Resolvi fazer eu mesmo uma réplica ao post anterior antes que os desenvolvedores comecem a me jogar pedras…

1. 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.
2. 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.
3. 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.
4. 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.
5. 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!
6. 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.
7. 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.
8. 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.
9. 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.
10. 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.
11. 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.
12. 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.

Este é um post inspirada no post do Insano Mundo de Jack que é um complemento do post no br-net.org que é uma tradução do post do Geeks are Sexy.

DBA’s são pessoas que trabalham entre os desenvolvedores (locais ou externos) e os adminstradores de sistema. Na minha curta experiência, os DBA’s costumam estabelecer relações mais amistosas com os Administradores de Sistema (que são poucos) e ter atritos com os desenvolvedores (que são muitos).

Então, aqui vão algumas dicas para o desenvolvedor (e em alguns casos usuários também) manterem uma relação produtiva com o seu DBA:

1. Se a sua aplicação parou de funcionar de repente, isto não significa que o banco de dados está fora do ar. A rede costuma ser o problema número um. Verifique se a rede está funcionando normalmente antes de por a culpa no banco de dados;
2. Entenda que o fato de uma aplicação ter desempenho adequado nos testes ou nos primeiros meses de produção, não significa que ela terá desempenho bom sempre. Os problemas de desempenho crescem geometricamente a partir de um certo volume de dados;
3. Por mais que você se considere um mestre em modelagem de dados, discuta o modelo com o seu DBA antes de sair implementando ele. O modelo de dados lógico nunca é igual ao modelo físico implementado pelo DBA;
4. Antes de sair desnormalizando o seu modelo de dados, tente seguir as formas normais e discuta os casos em que você acha conveniente fugir do modelo relacional com o seu DBA. Muitas veses isto não é vantajoso ou pode ser feito de forma transparente para a aplicação, ou só é vantajoso em alguns SGDBs.
5. DBAs não gostam de mudanças rápidas. Eles são resistentes a mudanças por natureza. Isto tem haver com a função deles. Linguagens de programação vem e vão e muitas vezes os bancos de dados continuam o mesmo. Veja que apesar dos modismos, a teoria relacional de bancos de dados continua firme há mais de 20 anos;
6. Nunca peça para realizar alterações no modelo de dados com pressa. Uma simples mudança de um campo em uma única tabela pode demandar semanas de planejamento cuidadoso. Se você apressar seu DBA para realizar as alterações, descobrirá que um erro cometido pelo DBA pode acarretar prejuízos incalculáveis para uma empresa.
7. Nunca, repito NUNCA solicite alteração em dados diretamente no ambiente de produção. Por favor, não insista!
8. Não peça permissões no ambiente de produção se você não está preparado para se responsabilizar pela perda daquelas informações.
9. Por mais que você seja um programador habilidoso, entenda que há operações que rodam de forma mais eficiente dentro do banco de dados. Aprenda a utilizar as linguagens procedurais do banco de dados e aprenda a utilizar subconsultas. É melhor perguntar para o seu DBA se você não souber, do que tentar resolver o problema sozinho.
10. Entenda que orientação a objetos pode ser a palavra de órdem entre as linguagens de programação, mas em materia de banco de dados suportando aplicações transacionais, isto não funciona, por mais que alguns vendedores tentem lhe convencer o contrário. Por mais que isto lhe pareça atraente, os SGDBs orientados a objeto não conseguiram provar sua robustez em ambientes de produção.
11. Não, diagramas UML não substituem as documentações clássicas utilizadas em banco de dados como o diagrama entidade relacionamento e dicionários de dados.
12. Veja seu DBA também como um desenvolvedor e não apenas como um administrador de sistemas. Ele é uma peça fundamental na homologação dos sistemas, mas se estiver presente no começo do projeto, muito tempo poderá ser economizado, a não ser que você tenha um Administrador de Dados realmente experiente na equipe.