Os anos de convívio com estes verdadeiros mastondontes, repletos de configurações, lentos e tinhosos mostraram-nos algo inegável:
Fuja de bancos de dados caros e complexos.
Um dos que atende completamente a este axioma é o banco Oracle. Mesmo com uma equipe treinada, com constante monitoramento, o mesmo pode amanhecer em "halt". Sai do ar. A arquitetura de volumes físicos e virtuais é tão flexível, que ele "estica" e rompe. Um banco que movimenta um grande número de transações precisa, como todos os outros com menos transações de capacidade, manter parâmetros na memória do servidor. Não existe processamento sem memória, e não existe memória saudável sem um fornecimento constante de energia dentro de picos razoáveis de voltagem e de corrente elétrica.
Se entre estes picos de corrente houver uma grande frequência de transações, a chance de uma perda é muito grande, como a prática confirma em nossa instalações. E não adianta reduzir a carga do banco, pois o Oracle "gosta" de trabalhar é com carga pesada.
Bancos grandes estão sendo superados por novas técnicas e pelo hardware que já vem com funções embutidas que atendem muito bem às exigências de robustez e velocidade.
Um dos bancos recentes, que aguenta, em volume menor de transações, o "tranco" é o Mysql. Em 7 anos de operação de um banco de CMS (Gerenciadores de conteúdo para Web) reparamos o banco apenas 2 vezes. E olha que ele sofre 12 mil atualizações, pelo menos, ao dia de cada requisição registrada de clientes.
E para bancos menores, em Intranet, o Microsoft Access se sai muito bem. Alguns técnicos incautos, acostumados a ouvir opiniões de outros de capacidade duvidosa e pouca experiência, falam que este banco não se presta a centenas de milhares de registros. Evidentemente se esquecem, ou nunca se deram conta, de que no servidor Web o banco de dados utilizado se comporta como se servisse a uma aplicação monousuário. Neste contexto, o usuário anônimo do servidor é o único autorizado a ler e a gravar no banco.
Já manipulamos bancos Access, via Web, com 4 milhões de registros, numa média de 8000 transações só de entrada em Intranet, e o banco não apresentou defeito em Servidor Microsoft Windows 2003.
Utilizando corretamente um banco de dados
Todo banco de dados dá uma boa resposta, se bem utilizado. Em primeiro lugar, é preciso uma boa modelagem das tabelas SEM UMA NORMALIZAÇÃO EXCESSIVA pois a recuperação dos dados fica extremamente trabalhosa para o banco. Não use excesso de códigos que precisam de tabelas de apoio para serem traduzidos. Depois, faça as suas sentenças SQL de forma a recuperar somente o que for preciso. Utilize a ordenação em suas SQLs só quando for ABSOLUTAMENTE NECESSÁRIO. A ordenação pode ficar a cargo do javascript, muito mais eficiente, e feita no lado cliente. Pense duas vezes antes de utilizar os "famintos" campos BLOB. Uma boa Gestão de Conhecimento vai possibilitar a tipificação de eventos e situações de forma a evitar o preenchimento "aberto" demais dos campos, com frases despadronizadas e cujo conteúdo talvez não seja achado em uma busca.
Um bom lembrete:
Se você não está a par do que é Gestão de Conhecimento, nem comece a definir o esquema das tabelas de seu banco de dados.
Conclusão
Para Intranets, use bancos pouco pretensiosos, programas com cache e bem feitos. Para Internet, use Mysql. Para aplicações pesadas em redes dispersas em áreas geográficas, empresas com muitas filiais e escritórios de apoio, além de centros de desenvolvimento, use Oracle, mas contrate uma boa equipe de analistas de suporte 24 horas por 7 dias na semana.
