É impressionante como é frequente ouvir que a base de dados de algum projeto apresenta performance muito abaixo do esperado. Na grande maioria das vezes, o problema principal é um desenho ruim do modelo do banco.
É triste pensar nisso, mas depois de 40 anos de desenvolvimento das técnicas de modelagem para bancos de dados relacionais, é surpreendente a quantidade de projetos que caem por terra em razão de uma modelagem mal feita.
Naturalmente, existe uma infinidade de aplicações que não precisam ter um modelo bem estruturado como é o caso do modelo relacional. Para estas aplicações, existem soluções mais adequadas do que os SGBDs relacionais. O crescimento assombroso do uso de ferramentas NOSQL é uma prova disso.
Porém, quando se trata de aplicações transacionais, não há nada melhor do que o modelo relacional. São décadas de evolução da tecnologia para que tenhamos resultados confiáveis, duradouros e com boa performance.
E os princípios básicos da modelagem relacional são tão simples que chega a ser estranho pensar porquê alguém deixaria de aplicá-los. Não estou dizendo que seja simples garantir a performance de qualquer tipo de banco de dados. A interação entre os objetos do modelo (tabelas, chaves e índices), os componentes de hardware (processadores, memória e discos) e os tipos de necessidade da aplicação (as consultas) sempre exigem uma boa dose de experiência e bom senso por parte de arquitetos e DBAs.
- Normalização do modelo não é perfumaria. Ela te ajuda a definir a estrutura do banco. Você não subiria num avião com falhas no projeto estrutural. Não imagine que possa ser diferente com a estrutura do seu banco de dados;
- Tem gente que acha q super chaves são um mero resultado da normalização (1FN) e não precisam ser formalmente definidas no banco de dados. Isso é uma visão absurdamente limitada. As super chaves são usadas pelos SGBDs para implementar um método rápido de pesquisa na tabela. Em quase todos os SGBDs que conheço, quando se cria uma chave primária, automaticamente está sendo criado um índice clusterizado. Portanto, toda tabela precisa ter uma chave primária;
- Um modelo relacional é baseado em …. relações (que surpresa, né). Quem formaliza as relações no banco são as chaves estrangeiras. Então por que tanta gente insiste em achar que elas são um estorvo para performance? Chaves estrangeiras garantem a qualidade das informações e, se bem implementadas, têm um impacto mínimo na performance;
- Dados devem ser associados aos seus domínios, ou seja, aos tipos de dados adequados: números inteiros, números decimais, cadeias de caracteres de tamanho fixo, cadeias de caracteres de tamanho variável, datas, etc. Claro que é mais fácil e mais rápido se o SGBD puder lidar com números e pequenas cadeias de caracteres. Por isso que se deve avaliar adequadamente o tipo de dados de cada coluna existente no banco. Já vi modelos em que a maioria dos campos usava tipo de dados CHAR. Isso costuma ser catastrófico em matéria de performance. Uma boa análise dos domínios pode eliminar esta dor de cabeça.
Fora a questão de modelagem em si, a definição de índices das tabelas é um complemento essencial. Como eu disse, ao criarmos uma chave primária numa tabela estamos automaticamente criando um índice clusterizado nesta tabela. Mas nem sempre isso é suficiente.
As tabelas maiores e/ou mais usadas normalmente precisam de índices extras. E, quando se tem um modelo bem arrumado em termos de super chaves, relações e tipos de dados dos campos, fica mais fácil escolher os índices mais adequados.
Na situação inversa, ou seja, quando temos um modelo mal desenhado, é bem provável que seja difícil conseguir bons índices, seja porque não existe um índice cluster para melhorar o desempenho deste(s) novo(s) índice(s), ou porque o modelo nos obriga a criar um índice baseado num conjunto muito grande campos, ou porque os tipos de dados dos campos usados no índice dificultam o bom desempenho deste índice.
Nas próximas semanas eu publicarei novos artigos analisando cada um destes tópicos em maior detalhe.
Até lá.
De 0 a 10, o quanto você recomendaria este artigo para um amigo?