Do que se trata o artigo

Este artigo aborda alguns pontos a serem levados em consideração na construção de sistemas no que diz respeito à performance de consultas nas aplicações que utilizarão o banco de dados. São apresentados e justificados itens que quando utilizados de forma incorreta tornam o sistema menos eficiente na busca e apresentação das informações, gerando problemas de velocidade de processamento nas operações de banco de dados.

Em que situação o tema útil

Uma vez que o desenvolvedor domina as técnicas de construção de pesquisas na linguagem SQL, é necessário indicar em quais estruturas de construção deverá ter mais cuidado ao elaborar suas pesquisas. Diversas situações de lentidão apontadas durante a operação de sistemas podem ser resolvidas com pequenos ajustes nas pesquisas e implementação de boas práticas, gerando melhorias e melhor aproveitamento dos recursos computacionais dos servidores de bancos de dados.

Resumo DevMan

Aplicações comerciais quase em sua totalidade utilizam algum mecanismo de banco de dados para armazenagem de suas informações, sendo que com o passar do tempo o volume de informações manipuladas pode crescer de forma a gerar lentidão e perda de desempenho dos sistemas. Observando-se pequenos ajustes feitos em rotinas do Microsoft SQL Server, foi possível notar melhorais isoladas nas pesquisas feitas na base dados, extraindo-se daí práticas de fácil implementação, mas que não são observadas por muitos desenvolvedores e que podem passar despercebidas até mesmo para a administração do banco de dados da empresa.

Foi utilizado como base a versão 2008 do MS SQL Server, por ainda estar em larga utilização nas empresas de TI da atualidade, porém muitas das técnicas tratadas também podem ser aplicadas a outras versões do gerenciador, dados os conceitos básicos aplicados.

Todos os caminhos levam a Roma. Pelo menos era o que os césares tentavam impor como verdade universal na época do Império Romano, indicando que todas as estradas tinham origem na capital do mundo antigo e, portanto levavam invariavelmente de volta a ela. Mas o que esta afirmação não deixava claro, e que vale até os dias atuais, é que mesmo quando a solução de um problema possui diversas abordagens, muitas delas nos levam a percorrer distâncias maiores e menos eficientes. Chegamos ao destino, porém despendemos recursos demais, “travamos” em algum ponto, e até mesmo atrapalhamos outros viajantes que estão utilizando estas rotas em suas atividades regulares. O que isto tem a ver com banco de dados? Praticamente tudo, uma vez que muitos programadores ainda acreditam que só porque uma query funcionou isoladamente ela está pronta para ser disponibilizada para o competitivo ambiente de produção.

Observa-se em ambientes de desenvolvimento de sistemas que programadores e, às vezes, até mesmo analistas e DBAs, reservam pouca ou nenhuma atenção à performance do banco de dados na construção de queries. Em alguns casos mais críticos, até mesmo serviços de consultoria dos fornecedores de bancos de dados precisam ser acionados para alertar sobre os principais erros que acarretam perdas de performance, pois até o DBA pode não conseguir mais isolar todas as situações.

É importante ressaltar que o trabalho de um DBA é voltado primeiramente para a manutenção de estruturas de bancos de dados, bem como políticas de acesso a estes e monitoração e otimização de performance de uma corporação, não devendo ser apenas uma figura de melhoria de escrita dos comandos. Naturalmente, estes profissionais podem contribuir em muito no trabalho de melhoria de performance de aplicações junto aos desenvolvedores, porém esta tarefa não deve alocar em demasia sua atuação e muito menos ser considerada como sendo sua função principal. Por ter acesso total aos SGBDs, sem contar a experiência de trabalhar com diversos sistemas instalados em ambientes distintos, o conhecimento e vivência do profissional de administração de banco de dados facilita a apresentação de soluções mais diretas nas análises de desempenho que venham a ser feitas no sistema. Na maioria dos casos, o DBA não é exclusivo do projeto, atuando como profissional de infraestrutura e apoio, um fornecedor de serviços, e por este motivo cabe ao desenvolvedor encará-lo como profissional atuante no quadro de colaboradores, evitando simplesmente direcionar eventuais problemas de lentidão para a responsabilidade da instalação do banco de dados.

Vale a pena destacar, antes de partir para a parte prática, que muitas vezes a maioria dos envolvidos é conivente com a situação, dos gestores aos programadores. Afinal, testa-se o sistema com meia dúzia de registros em uma base de desenvolvimento e devido a prazos apertados, que sempre estão presentes nos projetos de TI, libera-se o sistema da forma como está, deixando para o usuário final a tarefa de apontar onde estão os gargalos. Esta é uma forma reativa de abordar o problema e que deve ser evitada ao máximo. Construir e refinar as pesquisas mais pesadas de um banco de dados relacional, considerando-o somente como OLTP (ver ...

Quer ler esse conteúdo completo? Tenha acesso completo