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:
- 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;
- 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;
- 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;
- 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.
- 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;
- 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.
- Nunca, repito NUNCA solicite alteração em dados diretamente no ambiente de produção. Por favor, não insista!
- 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.
- 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.
- 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.
- 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.
- 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.
