Atenção: esse artigo tem um vídeo complementar. Clique e assista!

Bancos de dados estão presentes na maioria dos projetos de desenvolvimento de software, tanto desktop quanto Web. Dificilmente existirá uma aplicação que não utilize um SGBD para salvar e gerenciar dados.

O interessante da utilização do banco de dados é o desempenho que ele terá em longo prazo, pois normalmente ele começa limpo (sem dados), é rápido e eficaz. Entretanto, ao passar do tempo, a carga de dados inserida somada a outras ações, vão deteriorando sua performance. Principalmente se não escrevermos nossos objetos de banco corretamente.

Para isso somos obrigados a buscar melhores práticas para deixar a aplicação sempre disposta a receber e repassar uma grande quantidade de dados. Uma dessas práticas é a que vamos demonstrar neste artigo: a paginação de dados. Para isso, utilizaremos o SQL Server como SGBD.

Paginar significa pegar uma amostra X de dados e calcular outras quantidades de amostras possíveis para o usuário. Essas amostras são chamadas de páginas. Cada página pode ter um tamanho definido tanto pelo sistema quanto pelo usuário. Neste caso, já não dependemos do banco e sim das informações que serão enviadas para ele.

Paginar é necessário. Imagine procurar um sapato em uma loja de calçados onde toda a lista é apresentada de uma vez só. Além de ser uma operação lenta, é pouco interessante.

Na Internet podemos encontrar uma grande quantidade de informações e soluções de como fazer paginação, tanto no SQL Server quanto nas linguagens de programação (acessando o SQL e paginando via programação), mas as explicações não falam o porquê das coisas e não mostram o desempenho com quantidades grandes dados, que será a realidade abordada.

O Cenário de Ana Clara – Problemas com consulta a Produtos

Ana Clara, uma mulher de 54 anos (a um ano de sua aposentadoria), trabalha em um hipermercado chamado “Rede Bognar”, que possui 5 grandes lojas no Brasil, sendo que a sede principal (onde Ana trabalha) fica em São Paulo. O trabalho dela consiste em fazer uma verificação em duas listas: uma física e outra em um sistema Web criado para gerenciar informações dos hipermercados, como produtos, estoques, venda, ou seja, o ERP (Enterprise Resource Planning) da empresa.

Na lista física Ana possui uma quantidade imensa de produtos que não serão mais vendidos, ou nunca foram comprados. Na lista lógica ela consegue listar todos os produtos das 5 lojas da Rede, cerca de 1.500.000 produtos cadastrados (1.000.000 ativos), com crescimento diário. Os produtos da lista física devem ser desativados da lista lógica.

Ana reclama muito para o gerente de sua loja Paulo. Sua reclamação consiste na demora que ela tem em realizar seu trabalho. Ela diz a ele que sempre quando acaba de ver a listagem e muda a página para ver outra ou desativa um produto da lista e espera o recarregamento, tem tempo de ir tomar um café ou ficar fofocando com sua colega de trabalho. Porém, precisa fazer hora extra quase todo dia, caso contrário não consegue acabar com sua lista.

Intervenção da SQL Magazine para resolver o Problema de Ana Clara

Paulo, muito atencioso com seus funcionários, resolveu entrar em contato com a SQL Magazine para irmos a seu hipermercado verificar o problema apresentado por Ana e ajudá-la a resolver tal problema. Ao chegarmos, vimos um hipermercado grande, e aos fundos uma sala com cerca de 15 computadores. Paulo nos levou para a mesa de Ana e explicou o trabalho e o problema conforme descrito anteriormente.

Descobrimos que a lista física era bem grande com muitas folhas impressas com uma tabela que tinha um código numérico e o nome do produto. Paulo explicou mais sobre esta lista, dizendo que vem semanalmente da área de estoque e da gerência, os quais decidem quais produtos estarão estocados e vendidos ou não no próximo mês. Paulo mostrou e explicou também o sistema que Ana utiliza. É bem simples, feito por uma empresa terceirizada. O usuário pode colocar o código do produto e buscá-lo ou fazer a listagem de todos os produtos. Ana disse que sempre fazia a listagem geral, pois, segundo ela, listar 1.000 produtos por vez era mais vantajoso do que fazer um por um."